New features and enhancements
Starting in 11.2, connection strings and machine secrets are stored in {ProgramFolder}\Config\ instead of in each service-specific appsettings.json file.
{ProgramFolder}\Config\connectionStrings.jsonstores database connection strings and can be encrypted at rest.{ProgramFolder}\Config\machine.secrets.encstores DPAPI-protected secrets, including the ApplicationKey.Service-specific
appsettings.jsonfiles underWebsite,Api,DirectaService, andWebServiceno longer store connection strings after installation or upgrade.
After each production installation or upgrade, run nsscmd.exe -getconfig and store the output in a password vault or secure runbook. The ApplicationKey is required for disaster recovery, load-balanced server setup, and fresh installation against an existing database.
Upgrade preserves the installed ApplicationKey from the central configuration folder or supported legacy sources. Re-running upgrade with a different key in a staging file does not rotate the production key.
If the installation directory changes, upgrade copies the central Config folder from the old program folder to the new folder before database steps. The source Config folder is removed only after upgrade completes successfully.
The upgrade pre-check now reads database connection information from
{ProgramFolder}\Config\whenWebsite\appsettings.jsonno longer contains connection strings.For a fresh installation that uses an existing database, the Configurator validates the ApplicationKey from the previous installation and writes it to
Install.ini. ManualInstall.iniupdates are not required when you use the GUI.For a fresh installation that creates new databases, main and adapter database credentials are generated automatically.
UnInstall.bat keeps {ProgramFolder}\Config\ for disaster recovery. During reinstall, 11.2 handles leftover configuration as follows:
For a fresh installation with a new database, leftover Config data is removed before a new ApplicationKey is generated.
For reinstall with an existing database, Config data is kept when the ApplicationKey matches the database and removed when the key does not match.
Starting in 11.2, SilentInstall.bat and SilentUpgrade.bat are deprecated. Use the Configurator GUI for installation and upgrade. Command-line installation remains supported by editing Install Files\Install.ini and running Install Files\Install.bat as an administrator.
CSRF protection is enabled on relevant forms.
Disabled Windows accounts can no longer sign in to NSS.
JWT signing keys and machine secrets are protected with DPAPI.
The command nsscmd.exe -setsecret blocks ApplicationKey rotation after the initial configuration.
As part of the NSS 11.2 release, support has been added for Kubernetes and Nutanix within the existing VMware protection workflow.
This enhancement introduces a unified protection model where Kubernetes and Nutanix workloads now use the NetBackup policy template framework, similar to the existing VMware implementation. The previous protection logic for Kubernetes and Nutanix has been re-architected to align with the VMware workflow and reuse the same underlying logic.
With this change:
Protection plans created for Kubernetes and Nutanix workloads must use NetBackup policy templates, following the same approach currently used for VMware protection. NetBackup has been updated across all required components to support policy template integration for protecting Kubernetes pods and Nutanix clusters. The workflow provides consistency across VMware, Kubernetes, and Nutanix workload protection and simplifies protection plan management.
This enhancement standardizes workload protection by adopting a common policy-based architecture across supported platforms.
SQL Server workload usage is now calculated and reflected in NetBackup Self Service usage metrics.
Template changes made in Settings → Email Templates are now saved to the database. If you customized templates in 11.1 or earlier (XML under Website\EmailTemplates), back up those XML files before upgrade, then after upgrading to 11.2, re-enter each template in the customization screen and click once to store them in the database.
See the Configuration Guide for details.
A theme toggle in the header lets users switch between light and dark UI. The choice is remembered per browser.
CSRF protection added on relevant forms; disabled Windows accounts can no longer sign in to NSS
Uploaded images use Cohesity storage path instead of Veritas
Starting in release 11.2, Kubernetes and Nutanix workloads are protected using NSS policy templates, the same policy-based model used for VMware.
Impact
Kubernetes and Nutanix assets protected in releases earlier than 11.2 are not compatible with the new policy-based workflow.
After upgrading to release 11.2 or later, existing legacy protections and backup images for these workloads cannot be used for restore operations.
The legacy protection method is no longer supported in release 11.2 and later.
Required action
Re-protect Kubernetes and Nutanix assets by using the appropriate NSS policy template after upgrading. If legacy Kubernetes or Nutanix assets are still in use, plan their migration and re-protection before upgrading to release 11.2 or later.