Load-balanced installation and upgrade
This appendix provides the supported procedure for deploying NetBackup Self Service 11.2 or later, on multiple web servers that share one SQL Server instance containing the Main and Adapter databases.
Note:
Applies to NSS 11.2 or later with central {ProgramFolder}\Config\ created or migrated after installation.
A load-balanced NSS deployment consists of multiple IIS web servers running NSS and DirectaService behind a load balancer. All web servers use the same SQL Server instance for the Main and Adapter databases. Each web server retains its own local ProgramFolder and machine-specific DPAPI-protected secrets.
Table: Architecture requirements
Component | Requirement | Implementation |
|---|---|---|
SQL Server | One instance | Hosts both the Main and Adapter databases. |
IIS + DirectaService | One per web server | Each node has its own |
ApplicationKey + connection strings | Must match on every node | Stored in |
Uploaded images | Shared storage | Use the same UNC path on every node when users upload files. |
Note:
The Main database and Adapter database cannot be placed on different SQL Server instances. Install.ini and nsscmd -getconfig use a single DatabaseServer for both connection strings.
Complete the following requirements on every web server before installation.
Windows Server 2016 or later.
IIS and the .NET 10 hosting bundle. The installer can install prerequisites.
Network connectivity from each web server to the SQL Server instance over TCP, with required firewall rules.
SQL authentication or Windows authentication that works from each web server to the remote SQL Server.
A load balancer or DNS round-robin in front of the IIS sites. Configure it after the nodes are healthy.
A UNC share for uploaded images when users upload files. A shared image location is required for deployments with more than one web node.
Portal name (IIS application name). Use the same portal name on every node.
Database names on the shared SQL Server instance.
The ApplicationKey. All nodes must use the same ApplicationKey because they share the same SQL databases.
Note:
Each node has its own {ProgramFolder}\Config\machine.secrets.enc. This file is protected with Windows DPAPI on the local machine. Do not copy machine.secrets.enc between servers; DPAPI decryption fails on another machine.
Run the commands from {ProgramFolder}\Install Files on each node. The installed version folder is used in the path; for example:
C:\Program Files\Cohesity\NetBackup Self Service 11.2\Install Files
Table:
Command | Purpose |
|---|---|
nsscmd.exe -getconfig | Exports the ApplicationKey and connection fields as one semicolon-delimited string. Use it to back up the configuration and align other nodes. Central Config\ must exist. |
nsscmd.exe -setconfig "<string from getconfig>" | Applies the same secrets and connection strings to the local central Config\. The command restarts IIS and the local DirectaService. Config\ must already exist. |
nsscmd.exe -readconfig -programFolder "{ProgramFolder}" | Reads configuration from a specified ProgramFolder for diagnostics. |
Note:
Save the complete nsscmd -getconfig output from the primary node in a secure vault after the primary node is installed or upgraded. You need this output before uninstalling the primary node.
Use the primary-node plus workflow. This is the recommended NSS 11.2 deployment method because it avoids creating throwaway databases on secondary servers.
Install the primary web server (node 1)
Run
setup.exeand open the Configurator.Select .
Enter the Database Server. Specify the remote SQL host name, host\instance, or host,port.
Complete the installation. The installer generates the Main and Adapter database credentials.
Verify that you can log on to the portal.
Open an elevated command prompt and change to
{ProgramFolder}\Install Files.cd "{ProgramFolder}\Install Files"
nsscmd.exe -getconfig
Save the complete command output securely in a password vault or controlled runbook.
Install each additional web server (nodes 2 through N)
Run
setup.exeon the additional web server. NSS must not already be installed on this machine.In the Configurator, use the same portal name and IIS site choices as node 1.
Enter the same Database Server used by node 1.
Select .
Select and choose the same Main and Adapter database names used by node 1.
Enter the ApplicationKey from node 1. Use the hex value from nsscmd -getconfig or only the ApplicationKey= value.
Complete the installation. The -initconfig phase creates the local
{ProgramFolder}\Config\and attaches the node to the shared databases.
Note:
If the ApplicationKey is unavailable supply it by using Install.ini ApplicationKeyFile= or LegacyProgramFolder= as described in the Installation Guide.
Align configuration across all nodes
Even when secondary nodes use the same databases, run -setconfig on nodes 2 through N. This ensures that DAPI credentials and all connection fields match that of node 1.
On node 1, capture the configuration if it has not already been saved:
cd "{ProgramFolder}\Install Files"
nsscmd.exe -getconfig > \\secure-share\nss-node1-getconfig.txt
On each secondary node, run the following command from an elevated prompt. Replace the example string with the complete, single-line output from node 1.
nsscmd.exe -setconfig "ApplicationKey=...;MainDBServer=...;
MainDBName=...;MainDBUserName=...;MainDBPassword=...;
AdapterDBServer=...;AdapterDBName=...;AdapterDBUserName=...;
AdapterDBPassword=...;DapiUserName=...;DapiPassword=..."
Note:
Paste the entire single-line string returned by -getconfig. The -setconfig command validates that every required key is present. It also restarts IIS and the local DirectaService.
Configure shared uploaded images
Configure the same UNC path for uploaded images on every node. The uploaded-image path is not centralized in all configuration flows; confirm the path in the applicable administrator settings or integration configuration.
\\fileserver\NSSImages
Note:
The default local path %SYSTEMDRIVE%\inetpub\Cohesity\Images is local to each server. Change it to a shared UNC path for load-balanced deployments. See Reduced Database Permissions for Database Upgrade.
Configure the load balancer and validate the farm
Point the load balancer to each node's HTTPS binding. Use the same host-header and certificate strategy required by your environment.
Log on through the load-balancer URL.
Confirm that sessions work and that uploaded images are available.
On each node, confirm that DirectaService is running and that the Windows Event Log is clean.
Optionally run -getconfig on each node and compare the ApplicationKey. The ApplicationKey must match on every node.
Note:
Use this workflow only when is unavailable.
Install node 1 with new databases using the normal installation workflow.
On nodes 2 through N, install using new database names with a node-specific suffix, for example NetBackupSelfService2. The installer creates temporary databases.
On node 1, run nsscmd.exe -getconfig.
On nodes 2 through N, run nsscmd.exe -setconfig "<full string>" after installation has completed the -initconfig phase and Config\ exists.
In SQL Server Management Studio, drop the unused secondary-node databases.
For NSS 11.2, prefer to avoid the temporary databases and cleanup step.
For scripted secondary-node installations, edit Install Files\Install.ini before running Install.bat.
The following settings are from the source procedure; replace environment-specific values with your deployment values.
WebsiteName=Default Web Site ApplicationName=/NetBackupSelfService DatabaseServer=sql01.contoso.com UseWindowsAuthentication=0 UserNameForSA=sa PasswordForSA= DatabaseName=NetBackupSelfService AdapterDatabaseName=NetBackupSelfServiceNetBackupAdapter UseExistingDatabase=1 ApplicationKey=<hex key from node 1 getconfig> MainDBUserName=... MainDBPassword=... AdapterDBUserName=... AdapterDBPassword=... SystemBaseCurrency=USD SystemBaseLanguage=en-US
Run
Install Files\Install.batas Administrator.After installation, apply -setconfig from node 1 if you need an exact clone of DAPI settings.
There is no separate farm-upgrade wizard. Upgrade each web server that runs NSS.
Prepare for the upgrade
Back up both databases on the shared SQL Server instance.
On a reference node, run nsscmd.exe -getconfig and save the output.
Plan maintenance. Drain or stop the portal application pool on one node at a time while keeping the Public Web Service available according to standard upgrade guidance.
Upgrade the web servers
Upgrade node 1 using Configurator → .
Upgrade.batruns database scripts against the shared database and -migrateconfig on the local ProgramFolder.Verify the portal on node 1 and run -getconfig.
Upgrade nodes 2 through N one at a time using the same procedure. The Configurator detects the existing NSS installation on each machine.
Validate the database version after the first node before continuing. Although the database upgrade scripts are designed to be re-runnable, upgrade one node first and validate before proceeding.
After all nodes are on NSS 11.2, optionally run -setconfig from node 1 on any node where the -getconfig output differs.
Run -getconfig on the primary node again and update the secure vault copy.
Validate after the upgrade
Confirm that all nodes report the same ApplicationKey in -getconfig.
Confirm that the shared image UNC path is valid on every node.
Test failover through the load balancer.
Table: Troubleshooting scenarios
Symptom | Likely cause | Action |
|---|---|---|
-getconfig fails: "Central Node not yet on Phase 2 Complete install or upgrade" or configuration files were not found. | Central Config\ is missing. | Run the applicable -initconfig or -migrateconfig phase first. |
-setconfig fails: "Invalid values". | The configuration string is incomplete, for example DapiUserName or DapiPassword is missing. | Use the complete string from -getconfig on node 1. |
-setconfig fails: central config not found. | Installation did not finish on the node. | Complete the installation through -initconfig before running -setconfig. |
Secondary node cannot load existing databases. | The web server cannot reach SQL Server or authentication is incorrect. | From the web server, test the SQL connection with sqlcmd using the applicable server and credentials. |
Images are missing on some nodes. | PathForUploadedImages points to a local path instead of a shared UNC path. | Set the same UNC path on all nodes. |
Different ApplicationKey on two nodes. | A secondary node used the new-database path or the wrong ApplicationKey. | Run -setconfig from node 1, or reinstall the secondary node with UseExistingDatabase=1 and the correct key. |
ApplicationKey mismatch or validateconfig failed on node 2 or later. | A leftover | Confirm node 1's ApplicationKey. Reinstall using and the correct key. The installer removes stale Config\ when the supplied key does not match. As a last resort, delete |
Uninstall a single web server
In a load-balanced farm, running UnInstall.bat on one node removes that node's IIS applications and DirectaService. It preserves {ProgramFolder}\Config\ on that node and does not remove the shared SQL data.
Before uninstalling the primary node, save the complete nsscmd -getconfig output.
Uninstalling one web server does not remove shared SQL data.
Reinstall a secondary web server
.
Use the same ApplicationKey as node 1.
Do not select on nodes 2 through N.
NetBackup™ Self Service Installation Guide - prerequisites, GUI installation, upgrade, and Appendix E (customizing image upload).
ReadMe.txt- ApplicationKey backup, central Config\, and manualInstall.iniconfiguration.Two-server install - remote DatabaseServer rules for a deployment that uses one SQL Server instance for both databases.
All web servers can reach the shared SQL Server instance.
The same portal name is configured on every node.
The Main and Adapter databases reside on the same SQL Server instance.
All nodes use the same ApplicationKey.
Each node retains its own DPAPI-protected
machine.secrets.enc.Secondary nodes use for the shared Main and Adapter databases.
DAPI credentials and connection fields are aligned by using the complete -getconfig output and -setconfig where required.
All nodes use the same UNC path for uploaded images.
DirectaService is running on every node.
The portal works through the load-balancer URL.
Failover has been tested through the load balancer.
The latest primary-node -getconfig output is stored securely.