Skip to content

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 interface and Windows application use the same projects and cover the domain tasks in test management. Local operating-system functions use browser-adapted workflows or an approved Local Bridge.

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 web-area controls:

{
  "AppSettings": {
    "UseHttpsRedirection": true,
    "AllowInsecureCookies": false,
    "ExperimentalWebAreas": {
      "Enabled": true,
      "DisabledAreas": []
    }
  }
}

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.

Protection against repeated sign-in attempts

This protection requires an updated web server build that includes it. Configuration alone cannot add it to older installations.

Password sign-in for server administration and projects limits repeated failures per account and independently per IP address. Five failed attempts are allowed without a delay; the sixth failure starts a two-second wait. Further failures increase it to four, eight seconds and so on, up to five minutes. Successful sign-in clears only the account counter. IP limits remain in place so that a valid account cannot reset them.

During a wait, the form displays a message and returns HTTP 429 with Retry-After. Even a correct password can only be checked again after the wait expires. Accounts are not permanently disabled. Counters expire after 30 minutes without an admitted attempt; rejected requests do not extend the wait. Each IP also permits at most 30 admitted attempts per 60 seconds, with increasing IP delays after the twentieth failure. Consider these shared limits when many users share one public address.

Configure AppSettings.LoginProtection in appsettings.json:

{
  "AppSettings": {
    "LoginProtection": {
      "Enabled": true,
      "FreeAttempts": 5,
      "IpFreeAttempts": 20,
      "BaseDelaySeconds": 2,
      "MaxDelaySeconds": 300,
      "EntryExpirationMinutes": 30,
      "IpPermitLimit": 30,
      "IpWindowSeconds": 60,
      "MaxEntries": 10000,
      "InFlightSeconds": 120
    }
  }
}

InFlightSeconds limits the reservation for an unfinished password check. Concurrent checks of the same account are rejected; a reservation left by a crashed process is counted as a failed attempt after it expires. MaxEntries limits stored account and IP entries together. Retention must cover the maximum delay, IP window and reservation lifetime. Invalid settings are rejected. Restart the web application after changing configuration.

Counters persist in the LoginProtection subfolder of the private administration data directory. AppSettings.LoginProtectionStateDirectory can override this with an absolute path outside the webroot. All workers of one installation must share the same durable directory and have modification permission. Stored identifiers are derived values, not clear-text usernames or IP addresses. Do not delete this state during updates. If the administration data directory is inside the application directory, configure a separate durable state path before replacing that directory. An unavailable, full or corrupted store returns HTTP 503 rather than allowing an unprotected password check; check disk space, permissions and the server log.

File persistence is intended for workers on the same server. Multiple web servers require an additional shared limit at a trusted upstream service. Behind a reverse proxy, hosting configuration must provide the real client IP through a trusted path. Arbitrary X-Forwarded-For headers are not accepted as proof of identity.

This protection covers the application's browser password forms. Windows-to-web one-time token handoff, an explicitly configured password-free demo and projects without user management do not acquire an extra password prompt. API keys and external identity providers have separate security boundaries. Throttling does not replace HTTPS, strong passwords or protected server access.

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 the intended web workspaces. 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.

Regular web areas are enabled by default in version 6. The historically named ExperimentalWebAreas setting can disable individual areas; its name does not imply that all additional workspaces are preview features. AI requires separate configuration and approval.

For browser workflows, continue with Use Zeta Test Management in the web application. For connector and MCP setup, see Integrations and automation.