Network Management

SolarWinds Platform Active-Active solution

A completed SolarWinds Platform Active/Active installation provides you with a full duplicate of your existing SolarWinds environment for disaster recovery purposes. Deploy the Active/Active solution to reduce the downtime caused by maintenance or upgrades. During maintenance, synchronize databases, and run the post-restore script. Not suitable for customers with SolarWinds High Availability.

First published date

10/25/2018 2:13 PM

Last published date

7/9/2025 4:36 PM

Overview

SolarWinds Platform Active/Active installation is a deployment option that provides you with a duplicate of your SolarWinds installation for disaster recovery purposes. This deployment option is suitable only under special circumstances: it requires a special license and you need to regularly synchronize primary and secondary databases.

The SolarWinds Platform Active/Active solution is not suitable for customers who have deployed SolarWinds High Availability.

Download as PDF

Product section

Orion Platform

Resolution

Contents


Prepare a SolarWinds Platform Active/Active installation 

A completed SolarWinds Platform Active/Active installation provides you with a full duplicate of your existing SolarWinds environment for disaster recovery purposes.
 
Deploy the Active/Active solution to reduce the downtime caused by maintenance or upgrades.
The solution requires a special license. You need to regularly synchronize primary and secondary databases.
 

Limitations 

  • The agents deployed in the network and connected to the primary server do not reconnect to the secondary server in the event of a primary outage (this is supported in HA solution).
  • The traps, syslogs, NetFlow traffic, and the majority of the data that the device-initiated communication (VNQM Avaya, and so on) collects are going to the configured destinations. Some devices support multiple recipients. See the section "Handle passive monitoring (NetFlow, Syslog, and SNMP Traps) for Active/Active deployments". 
  • If you limit devices to accept the traffic just from certain IPs, both the primary and secondary server must be on the device white list.
  • Alerts and Alert actions, such as email messages, are duplicated and triggered from both primary and secondary SolarWinds Platform servers.
  • Actions that access external files (for example, scripts) do not work unless you synchronize the files.
  • Scheduled reports for NPM are duplicated.
  • During database maintenance when SolarWinds Platform Services are shut down, gaps in monitoring may occur:
    • Gaps in monitoring on the primary SolarWinds Platform server during the backup period.
    • Gaps in monitoring on the secondary SolarWinds Platform server during the restore period.
    • There might be inconsistencies in some charts in the secondary environment because not all counters are measured at the exact same time in both environments.
Visit our Thwack Community or the SolarWinds Success Center to find tips about how to manage gaps in monitoring.
 

Active-Active deployment requirements 

  • SolarWinds Platform must be 2016.2 and later.
  • Server hardware and software specifications must meet or exceed the requirements of your SolarWinds Platform environment. See SolarWinds Platform requirements in the Customer Success Center.
  • SQL database requirements must meet or exceed the requirements for the SolarWinds Platform database. See SolarWinds Platform requirements.
  • All user account credentials must have administrative rights on both the primary SolarWinds Platform server and the secondary SolarWinds Platform server in the SolarWinds Platform Active/Active configuration.
  • Licenses must be registered for all SolarWinds Platform products installed on your secondary SolarWinds Platform server.

SolarWinds recommendations for the SQL database in an Active/Active deployment 

  • Install the database for the secondary SolarWinds Platform server on its own physical server.
  • Install the proprietary SQL server management tool on both the primary and the secondary database servers.
  • Do not use a Microsoft SQL Server Express database. Its storage is limited to 10 GB, and RAM is limited to 1 GB.
  • Prepare the credentials:
    • Have available the password to the sa accounts for both your primary and your secondary SolarWinds Platform database servers.
    • Have available the credentials to accounts with administrative rights on both the primary and secondary SolarWinds Platform database servers.
  • SQL AlwaysOn is supported in SolarWinds Platform products running SQL Server 2012 or later. Although that feature is not influenced by an Active/Active deployment, there are other considerations to be aware of.

Active/Active license requirements 

  • All products installed on the primary server match all of the products installed on the secondary server.
  • The license agreement requires that the secondary SolarWinds Platform instance be used solely to monitor the same entities that are monitored on the primary instance.
  • The license levels for each installed product must match on the primary and secondary instance.

Preflight check 

Before you set up your SolarWinds Platform Active/Active solution, complete the pre-installation checklist below. This checklist helps you:
  • Verify that system requirements are met, all required software is installed, and required roles and features are enabled.
  • Gather the information required to complete the installation.
Review release notes
Review release notes and available documentation for your SolarWinds Platform products in the Success Center.
Review system requirements
Make sure your environment has all of the required hardware, software, and database requirements for your installations.
Prepare product license
Review your current product licenses for SolarWinds Platform products on your primary server, and determine if you need to make any changes. You can download any updated license keys through the Customer Portal.
For information about the secondary server licenses, contact your SolarWinds account manager or SolarWinds.
Gather credentials
Make sure you have all account credentials, SQL database credentials, your SolarWinds account, and local admin server credentials.
Use the Local Administrator Account for installation.
The Local Administrator Account is not the same as a domain account with local admin rights. A domain account is subject to your domain group policies.
To download SolarWinds products and licenses, you need a SolarWinds Customer Portal account.
Schedule the installation
Set up the maintenance window, preferably during off-peak hours. Depending on the number of products, size of databases, and size of environment, you may need hours to complete your installation.
Installations in an existing SolarWinds Platform environment require polling engines and SolarWinds services to be offline for a length of time, causing you to lose a portion of polling data.
Notify your company
Send a message to your company about the installation schedule and maintenance window. If you need additional help with the installation process, contact and allocate staff to be available.


Prepare for the install 

As part of your preflight, prepare the server or upgrade the existing SolarWinds Platform environment:
 
1. Prepare the environment
  • For new server installations, build the servers based on your deployment size and system requirements.
  • For installations into an existing SolarWinds Platform, verify that enough drive space is available for installations.
  • For an SolarWinds Platform installation or integration, you may need to build Additional Polling Engines, and an Additional Web Server. For details, see the SolarWinds Scalability Guidelines.
2. Run all Windows updatesBefore installation, check for and run all Microsoft Windows Updates on all servers. As you install, if a Windows update runs, your system may reboot as needed by Windows. The installation cannot complete if your system is waiting to reboot.
3. Open ports according to requirementsFor your server ports and firewall, open ports according to the system requirements. The SolarWinds Platform uses these ports  to send and receive data.
4. Check for antivirus software
Determine if any antivirus software is installed on the server or servers where you plan to install. To ensure the installation goes smoothly, exclude the SolarWinds directory. For example, on Windows Server 2012 R2, exclude C:\ProgramData\SolarWinds\. For a full list of antivirus exclusions, see Files and directories to exclude from antivirus scanning for SolarWinds Platform products.
SolarWinds assumes that C:\ is the default volume.

Set up the Active/Active deployment 

Install the SolarWinds Platform and configure the database for both the primary and secondary environment. This is a one-time action, repeated only when you decide to upgrade your deployment.
 
1. Install the SolarWinds Platform on the primary server.
Log in to the primary server and install the software.
For more information, see the SolarWinds Platform Installer or the Installation Guide for your SolarWinds Platform products.
2. Make a full backup of the production database.
Check your vendor's site for documentation and instructions.
If you have your database on a VM, create a snapshot or copy of your VM.
To back up your Microsoft SQL database, download and install Microsoft SQL Management Studio Express on your SolarWinds Platform SQL database server.
3. Install your SolarWinds Platform products on the secondary server.
Log in to the secondary server and install your SolarWinds Platform products.
Don't run the Configuration wizard. If you already ran the Configuration wizard, remove the SolarWinds-Orion certificate from the store.
  1. Press the <Windows Key>+ <R>, enter mmc.exe and press Enter.
  2. Click File > Add/RemoveSnap-in.
  3. Select Certificates and click Add.
  4. Select the Computer account, and complete the wizard.
  5. Navigate to Personal > Certificates, and locate the SolarWinds-Orion certificate.
  6. Delete the certificate.
4. Restore the database.
Restore the database from its backup on the secondary SQL server. This creates a new database from the backup on the secondary server.
You may need to adjust the database user role. See the Troubleshooting section.
5. Run and modify the post-restore script.On the secondary server, modify and run the post-restore script against the secondary database. See the Run the post-restore script section.
6. Run the Configuration wizard on the secondary server.
The Configuration wizard connects the secondary server to the newly created database.
The Configuration wizard may fail on the migration.exe utility due to Licensing security. This issue is corrected by the next steps.
7. Reset the license.
8. Add a license key.
Activate the secondary server licenses on the secondary server. Contact support to get the Active/Active license keys.


Prepare a separate database 

After you install your Active/Active environment, prepare a separate database for storing data that cannot be updated by the post-restore script. These data include your licensing information.
 
When you upgrade your SolarWinds Platform products, SolarWinds recommends that you delete and create the backup database from scratch. This is because the database schema may differ across the SolarWinds Platform releases.
  1. Log in to the server hosting your secondary SQL database.
  2. Review the following script, and provide the database name. In this example, the database is called OrionTablesBackupDB.
    CREATE DATABASE OrionTablesBackupDB --<<==== Choose a DB name for the temporary storage. This will be further used in the scripts
    GO
  3. Open the Microsoft SQL Management Studio, and run the updated script to create the database.
  4. Create the database tables:
    1. In the SQL Management Studio, right-click the secondary database, and select Tasks > Generate Scripts.



    2. Select tables with the prefix dbo.Licensing_*.



    3. Complete the wizard. By default, the wizard generates only the schema, you don't need to modify anything. The script is created.
    4. Open the script, and modify the database name to the name of the database you created.
    5. Launch the script (F5) to create the tables.
      The list of the tables defines the tables to be backed up, and copied back after you restore the database. The script is created.

    6. In SQL Server Management Studio, select the helping database OrionTablesBackupDB, and launch the following script against it. The script creates stored procedures that move the data between the source (primary) and backup databases.
      IF NOT EXISTS (SELECT * FROM sys.types WHERE name='TablesToBackupType')
      BEGIN
      CREATE TYPE TablesToBackupType AS TABLE
      (
      [tableToBackup] [varchar](120) NOT NULL
      )
      END
      
      
      IF EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[sp_GetDelimitedListOfColumnsForTableNoIdentity]'))
      BEGIN
      DROP PROCEDURE sp_GetDelimitedListOfColumnsForTableNoIdentity
      END
      GO
      CREATE PROCEDURE sp_GetDelimitedListOfColumnsForTableNoIdentity (@currentTableName nvarchar(120), @columnListCommaDelimited nvarchar(max) out)
      AS
      DECLARE @loopCounter INT=0;
      DECLARE @tableColumns table (columnName varchar(100))
      SET @columnListCommaDelimited = ''
      DECLARE @currentColumnName nvarchar(max)
      DECLARE columnIterator CURSOR LOCAL FAST_FORWARD FOR SELECT columnName FROM @tableColumns;
      OPEN columnIterator
      INSERT INTO @tableColumns(columnName) select c.name from sys.columns c inner join sysobjects so on c.object_id=so.id WHERE c.is_identity=0 AND so.name= @currentTableName
      DECLARE @columnCount int
      SET @columnCount = (SELECT Count(*) from @tableColumns)
      WHILE @loopCounter < @columnCount
      BEGIN
      FETCH NEXT FROM columnIterator Into @currentColumnName;
      IF @loopCounter < @columnCount-1
      SET @columnListCommaDelimited += (@currentColumnName + ', ')
      ELSE
      SET @columnListCommaDelimited += @currentColumnName
      SET @loopCounter = @loopCounter + 1;
      END
      CLOSE columnIterator;
      DEALLOCATE columnIterator;
      GO
      
      
      IF EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[sp_CopyFromSourceDBtoTargetDBnoIdentity]'))
      BEGIN
      DROP PROCEDURE sp_CopyFromSourceDBtoTargetDBnoIdentity
      END
      GO
      
      
      CREATE PROCEDURE sp_CopyFromSourceDBtoTargetDBnoIdentity (@sourceDB nvarchar(120), @targetDB nvarchar(120), @tablesToBackup TablesToBackupType READONLY)
      AS
      DECLARE @loopCounter INT=0;
      DECLARE @currentTableName varchar(100)
      DECLARE tablesIterator CURSOR LOCAL FAST_FORWARD FOR SELECT tableToBackup FROM @tablesToBackup;
      OPEN tablesIterator
      WHILE @loopCounter < (SELECT Count(*) from @tablesToBackup)
      BEGIN
      FETCH NEXT FROM tablesIterator Into @currentTableName;
      DECLARE @targetTableCleanupCommand nvarchar(max) = 'DELETE FROM ' + @targetDB + '.dbo.' + @currentTableName;
      EXEC sp_executesql @targetTableCleanupCommand
      IF EXISTS (select c.name from sys.columns c inner join sysobjects so on c.object_id=so.id WHERE c.is_identity=1 AND so.name= @currentTableName)
      BEGIN
      DECLARE @reseedTargetTableIdentityCommand nvarchar(max) = 'DBCC CHECKIDENT (''[' + @currentTableName + ']'', RESEED, 0)';
      EXEC sp_executesql @reseedTargetTableIdentityCommand -- Reset the identity value back to 0 to avoid identity type overflow by often rewrite operations
      END
      DECLARE @columnList nvarchar(max) = ''
      EXEC sp_GetDelimitedListOfColumnsForTableNoIdentity @currentTableName, @columnList out
      DECLARE @backupTableCommand nvarchar(max) = 'INSERT INTO ' + @targetDB + '.dbo.' + @currentTableName + '('+ @columnList + ') SELECT '+ @columnList +' FROM ' + @sourceDB + '.dbo.' + @currentTableName;
      EXEC sp_executesql @backupTableCommand
      
      
      SET @loopCounter = @loopCounter + 1;
      END
      CLOSE tablesIterator;
      DEALLOCATE tablesIterator;
      GO
      -- Scripts are not supported under any SolarWinds support program or service.
      -- Scripts are provided AS IS without warranty of any kind. SolarWinds further
      -- disclaims all warranties including, without limitation, any implied warranties
      -- of merchantability or of fitness for a particular purpose. The risk arising
      -- out of the use or performance of the scripts and documentation stays with you.
      -- In no event shall SolarWinds or anyone else involved in the creation,
      -- production, or delivery of the scripts be liable for any damages whatsoever
      -- (including, without limitation, damages for loss of business profits, business
      -- interruption, loss of business information, or other pecuniary loss) arising
      -- out of the use of or inability to use the scripts or documentation.
You have now created the OrionTablesBackupDB database for backing up licensing data that must not be overwritten by the post-restore script. The licensing data stays in the backup database and the scripts you have set up copy the licensing data from the backup to the synchronized database.

Synchronize the SolarWinds Platform Active/Active environment for maintenance 

Synchronize your SolarWinds Platform Active/Active environment regularly to maintain consistent monitoring.

When to synchronize databases? 

  • During the scheduled database maintenance
  • When SolarWinds Platform objects are added, removed, or modified in the SolarWinds Platform. For example:
    • Devices
    • Credentials
    • Custom properties
    • Application monitor templates
    • Application components

Maintenance step 1: Synchronize the databases 

To keep the primary and secondary databases synchronized, complete the following steps regularly.
  1. Back up the source database (primary SQL server):
    Log in to the primary SQL server, and run the backup script.
    Consult the script with your database administrator to adjust preferred media and backup style.
    The following example backs up the database to a shared network drive.
    USE master;
    BACKUP DATABASE SolarWindsOrionMain
    TO DISK = '\\10.140.26.196\Backups\DBBackup.bak'
    GO
     
  2. Restore to the target DB (secondary SQL server):
    Log in to the secondary SQL server, and run the restore script.
    The following example script:
    • backs up the licensing data to the helping database (temporary storage, called OrionTablesBackupDB in this example)
    • restores the primary database backup on the secondary SQL server database
    • copies the licensing data from the helping database to the secondary SQL server database
    Contact your database administrator for the correct restore script for your database. Adjust the information with comments to your environment.
    USE [OrionTablesBackupDB] -- <== Set here the name of the backup DB
    DECLARE @tablesToBackup TablesToBackupType
    INSERT INTO @tablesToBackup select name from sys.tables;
    
    DECLARE @backupDB nvarchar(max) = 'OrionTablesBackupDB' -- <== Set here the name of the backup DB (temporary storage)
    DECLARE @mainDB nvarchar(max) = 'SolarWindsOrionSecondary' -- <==Set here the name of the backup SolarWinds Platform DB
    
    DECLARE @dbBackupLocation nvarchar(max) = '\\10.140.26.196\Backups\DBBackup.bak' -- <== Use this if you use DISK storage. If you use other ways, like TAPE, check directly @restoreCommand to modify
    
    --Copy data to backup DB
    EXEC sp_CopyFromSourceDBtoTargetDBnoIdentity @mainDB, @backupDB, @tablesToBackup
    
    --Restore itself
    
    DECLARE @restoreCommand nvarchar(max) = '
    SET DEADLOCK_PRIORITY HIGH;ALTER DATABASE [' + @mainDB + '] SET SINGLE_USER WITH ROLLBACK IMMEDIATE; RESTORE DATABASE [' + @mainDB + '] FROM DISK=''' + @dbBackupLocation + ''''
    exec sp_executesql @restorecommand
    
    --Copy data back
    
    EXEC sp_CopyFromSourceDBtoTargetDBnoIdentity @backupDB, @mainDB, @tablesToBackup
You have synchronized your primary and secondary database. Next, run the post-restore script.
 

Troubleshooting 

Database left in Single User Mode during the restore

If the database was left in 'Single User Mode' during the restore, run the following script.
 
Use master; SET DEADLOCK_PRIORITY HIGH;ALTER DATABASE [SolarWindsOrionSecondary] SET MULTI_USER
 

Broken login after the restore

Although the logins use the same credential set on both SQL instances, the classic public logins cannot substitute each other.
To resolve the issue, give the SolarWinds DB user the sysadmin role to operate all the databases.
 

Maintenance step 2: Run the post-restore script 

After each restore, run the post-restore script. It replaces the hostname references in the database backup from the source instance (primary database) to the target instance (secondary database).
Make sure you correctly define the variable @hostnamesMap. It defines the primary SolarWinds Platform server name (source) and maps it to the secondary SolarWinds Platform server name (target). The variable affects internal data, such as the definition of endpoints the SolarWinds Platform services communicate with.

If you have Additional Polling Engines (APEs) and Additional Web Servers (AWS) in your environment, specify the primary and secondary hostname in the hostnamesMap for each APE and AWS.
The script does not replace the SwisUriSystemIdentifier and its references, such as Dependencies or ContainerMemberDefinitions. This is because there may be a huge amount of these references, and the script results may be unpredictable across module combinations. In consequence, you cannot federate both instances at the same time, for example in SolarWinds EOC.
If you have DPA installed, Remove integration with a DPA server manually  together with the post-restore script. To do so, add the script from the DPA article at the end of the post-restore script, and run the script.
 

Run the post-restore script:

USE SolarWindsOrionSecondary --<<======= UPDATE to the target DB name
DECLARE @hostnamesMap table(sourceHostname varchar(100), targetHostname varchar(100))
/*DEFINE servers mapping. First element is the name of the server from source database, second from target. Add row per each another server (APE, AWS) in the system*/
INSERT INTO @hostnamesMap(sourceHostname, targetHostname) VALUES
('source1', 'target1') --<<====== update
,('source2', 'target2') --<<====== update/remove/add next pair if needed


DECLARE enginesIterator CURSOR LOCAL FAST_FORWARD FOR SELECT sourceHostname, targetHostname FROM @hostnamesMap;
DECLARE @loopCounter int=0;
DECLARE @serversCount int = (SELECT Count(*) from @hostnamesMap)
DECLARE @currentTargetHostname varchar(100)
DECLARE @currentSourceHostname varchar(100)
OPEN enginesIterator
WHILE @loopCounter < @serversCount
BEGIN
FETCH NEXT FROM enginesIterator Into @currentSourceHostname, @currentTargetHostname;
/*UPDATE SECTION BEGIN*/
UPDATE ENGINES SET ServerName = @currentTargetHostname WHERE ServerName = @currentSourceHostname
UPDATE Websites SET ServerName = @currentTargetHostname WHERE ServerName = @currentSourceHostname
UPDATE WebSettings SET SettingValue = @currentTargetHostname WHERE SettingName='JobSchedulerHost' AND SettingValue = @currentSourceHostname;
UPDATE WebSettings SET SettingValue = @currentTargetHostname WHERE SettingName='LicensingMainServerName' AND SettingValue = @currentSourceHostname;
UPDATE OrionServers SET HostName = @currentTargetHostname WHERE HostName = @currentSourceHostname
UPDATE Sites SET Name=@currentTargetHostname, Host=@currentTargetHostname WHERE Host=@currentSourceHostname
/*UPDATE SECTION END*/
/*CLEANUP SECTION BEGIN*/
DELETE FROM PendingNotifications WHERE Subscription_Id IN (SELECT Id FROM Subscriptions WHERE EndpointAddress LIKE 'net.tcp://' + @currentSourceHostname + '%' OR EndpointAddress LIKE 'inproc://' + @currentSourceHostname + '%' OR EndpointAddress LIKE 'active://' + @currentSourceHostname + '%' OR EndpointAddress LIKE 'bus://' + @currentSourceHostname + '%');
DELETE FROM Subscriptions WHERE EndpointAddress LIKE 'net.tcp://' + @currentSourceHostname + '%' OR EndpointAddress LIKE 'inproc://' + @currentSourceHostname + '%' OR EndpointAddress LIKE 'active://' + @currentSourceHostname + '%' OR EndpointAddress LIKE 'bus://' + @currentSourceHostname + '%';
DELETE FROM ServiceDirectoryEntries
/*CLEANUP SECTION END*/


SET @loopCounter = @loopCounter + 1;
END
CLOSE enginesIterator;
DEALLOCATE enginesIterator;
GO   
The script has updated hostname references in the secondary database.

Handle passive monitoring (NetFlow, Syslog, and SNMP Traps) for Active/Active deployments 

If your primary SolarWinds environment uses NetFlow, syslog, or SNMP traps for passive monitoring, configure all passively monitored devices to send messages both to your primary SolarWinds Platform server and to your secondary SolarWinds Platform server in an Active/Active configuration.
 

Configure NetFlow monitoring 

Configure each NetFlow-enabled device monitored by your primary SolarWinds Platform server to send Flow data to the secondary SolarWinds Platform server in an Active/Active configuration.
The specific commands for individual devices may vary, but, in general, the required commands are as follows:
  • ip flow-export version 5
  • ip flow-export destination <ip_address_primary> 2055
  • ip flow-export destination <ip_address_secondary> 2055
In this example <ip_address_primary> is the IP address of your primary SolarWinds Platform server, and <ip_address_secondary> is the IP address of your secondary SolarWinds Platform server.
For more detailed information about configuring NetFlow-enabled devices for monitoring, see Configure devices for Flow collection in the NTA online help.
 

Configure Syslogs 

To ensure continuity of monitoring using syslog, duplicate syslog messaging for the secondary SolarWinds Platform server.
Run the command line interface, and add the secondary SolarWinds Platform server as a syslog receiver for each syslog-enabled device.
 
For most devices, the commands are similar to the following:
  • NodeName(config)#logging ip_address_primary
  • NodeName(config)#logging ip_address_secondary
where ip_address_primary is the IP address of the primary SolarWinds Platform server, and ip_address_secondary is the IP address of the secondary SolarWinds Platform server in your SolarWinds Platform Active/Active environment.
 
Apply the command to all devices for which you want to maintain syslog monitoring. For more information, see Monitor Syslog messages  in the SolarWinds Platform Administrator Guide.
 

Configure SNMP traps 

To enable SNMP trap messaging to the secondary SolarWinds Platform server, indicate the IP address of your secondary SolarWinds Platform server as an additional receiver of SNMP traps.
 
The commands required for most devices are similar to the following:
  • NodeName(config)#snmp-server host ip_address_primary public
  • NodeName(config)#snmp-server host ip_address_secondary public
where ip_address_primary is the IP address of the primary SolarWinds Platform server, and ip_address_secondary is the IP address of the secondary SolarWinds Platform server in your SolarWinds Platform Active/Active environment.
 
For details, see Monitor SNMP traps  in the SolarWinds Platform Administrator Guide. Note that in SolarWinds Platform Platform 2019.4 and later, you can optionally manage Syslog and SNMP trap messages through the SolarWinds Platform Web Console using the free Log Viewer (LV).