Migrate SolarWinds Orion products to a new server with a new IP or hostname
Last Updated: November 19, 2018 | Migration Guide
Supports: SolarWinds products with Orion Platform 2016.1 and later, such as NTA 4.2 or SRM 6.3
When migrating your Orion Server to a new server using a new IP or hostname different than the current server, install the product on the new server, move reports, import SSL certificates, reassign nodes, and redeploy agents.
How do I migrate?
- Prepare the new server for the Orion server.
- Migrate your product to the new server.
- Migrate integration modules.
Migrating the Orion SQL database, NTA Flow Storage database, or both? Complete the database migration before migrating your Orion Platform products.
|1. Prep new hardware for the migration||
Build the new server including any changes to the architecture, hardware, and Operating System.
Product requirements include:
For all port requirements, see Port Requirements for all SolarWinds products.
See URLs used by the Orion Platform for a list of URLs to add as exceptions to your firewall.
|2. Gather credentials||Gather the local admin credentials for the current and new server.|
|3. Get SolarWinds installation files||Download the SolarWinds product installation files from the Customer Portal. Copy the files to the new server.|
Depending on the products you migrate, you may have different steps to take such as transferring SSL certificates, redeploying agents, and moving files.
Note on Capitalization: Queries are case sensitive for the stored values in the database. Check the stored value capitalization prior to running queries in these steps. If a stored values for a hostname is in ALL CAPS, CamelCase, or all lower case, you must match the capitalization in your query.
|1. Delete your High Availability pools (Optional)||If your server is a member of an HA pool, delete the pool.|
|2. Release the product license||
Release the product license on the original server.
Orion Platform 2016.2 and later products
In Orion Platform 2016.2 and later (example NPM 12.0.1, SAM 6.9), you must use the web-based License Manager when migrating your main Orion server.
If you are offline, save the deactivation receipt file, and then upload the deactivation file:
Orion Platform 2016.1 and earlier products
In Orion Platform 2016.1 and earlier (example NPM 12.0 and 11.5.3), certain products can deactivate licenses through the product internal licensing tool or the stand-alone License Manager.
If you are offline, you need to then upload the deactivation file:
The deactivated licenses are now available to activate on a new server.
|3. Stop the SolarWinds High Availability Service||If HA is installed, go to services.msc and stop the SolarWinds.HighAvailability.Service on the old server.|
|4. Stop Orion services||Stop services on the original polling server. You can leave the original server running.|
|5. Back up your database||
Back up your current database before migration.
If your SQL database is on a VM, create a snapshot of the VM.
If your SQL database is on a server, you can use SQL Management Studio Express for your specific version of Microsoft SQL on your Orion SQL database server. See the Microsoft article Create a Full Database Backup for details (©2019 Microsoft, available at https://www.microsoft.com, obtained on October 10, 2019).
Use the following links to download the installation for the latest version, which is backward compatible with older versions:
SFTP users created do not get carried over to the new App server, and you should also backup your SFTP_Root folder as well.
|6. Back up files (Optional)||
(Optional) If you have legacy reports, back up the reports folder to save your custom reports:
For NCM, you may need to back up the following folders (found in C:\Program Files\SolarWinds\Orion\NCM or C:\Program Files (x86)\SolarWinds\Orion\NCM):
|7. Install products||
Unzip and install the new Orion product.
Do not run the Configuration wizard.
If you migrate as part of an upgrade, follow the upgrade path for your upgrades. Depending on the upgrade path and requirements for new product versions, you may need to migrate to new servers and OS before upgrading Orion products.
Need more information? Check our SolarWinds Upgrade Guide.
|8. Update references to the old server and remove HA entries||
Replace all references to the old server with the new server name.
You must use the NetBIOS short names to the old and new servers to complete this step. Run the hostname command from the command line to confirm the server names. If you have decommissioned the old server completely, look in the Engines table for this information.
|9. Run the Configuration wizard||
Run the Configuration wizard on the new server and restart all Orion services.
What you should do:
Need more information? Check our SolarWinds Upgrade Guide.
|10. Restart the SolarWinds Administration service||Restart the SolarWinds.Administration service on all servers in the environment.|
|11. Move the license store
Orion Platform 2016.2 - 2017.1
Complete this step if your products are on Orion Platform 2016.2 - 2017.1, such as NPM 12.0.1 and SAM 6.3. If not, continue to the next step.
If you are migrating the main Orion server, you must move the license store.
|12. Re-initialize the license store||If you are running Orion Platform 2017.3 and later, re-initialize the license store.|
|13. Enable the product license||
Enable the product license on the new server.
Orion Platform 2016.2 and later
In Orion Platform 2016.2 and later, you must use the web-based License Manager when migrating your main Orion server.
If you are offline, do the following:
Orion Platform 2016.1 and earlier
In Orion Platform 2016.1 and earlier, certain products can activate licenses through the product internal licensing tool or the stand-alone License Manager.
To activate using the License Manager:
If you are offline, you need to complete a few extra steps:
14. Redeploy or reconnect to Agents
You have multiple options for deploying or reconnecting to existing Agents during a migration. You can:
15. Copy legacy reports to the server, upgrade report schemas
Copy other files as needed
Copy the reports folder to the same directory as on the old server on the new server:
Orion Platform 2016.1 and earlier
You must upgrade the report schemas in the new install. Updating the report schemas allows Report Writer to display and use custom property information.
Copy over other files as needed. If you have migrated NCM, you may need to merge folder contents with the following (found in C:\Program Files\SolarWinds\Orion\NCM or C:\Program Files (x86)\SolarWinds\Orion\NCM):
|16. Validate SNMP and WMI requests||Validate all devices are set to allow SNMP and WMI requests from the new web address as appropriate.|
17. Transfer SSL certificates
For website SSL certificates, you will need to transfer the certificate to the new server. Review the documentation from your SSL vendor to migrate the certificate. You will need the CSR, private key, and certificate.
If you use a self-signed SSL certificate, you must create a new self-signed certificate for the new server IP and hostname.
|18. Recreate your High Availability pool||
If your server was an HA pool member, recreate your HA pool. This is for SolarWinds HA, not FailOver Engine HA.
For details on SolarWinds HA, see this article.
In the web console, you should see the node displaying the new IP and host name in Manage Nodes. All polling engines should be assigned to the new server.
Uninstall the products from your original server to use the server for other needs and products.
Delete the product install zip files to save space.
Subscriptions table showing original server
This applies to migrations to products running on Orion Platform 2016.1 and earlier. One possible issue that may occur is the original server showing in the subscriptions table of the database. This information is dynamic, created during service startup. If you see old info pointing to the original polling engine in the subscriptions table, change the following:
In the database, go to the subscriptions table then the column
Expand out to see hostname or ip of the server: port: subscription.
If you see the old IP and host name, stop services and run the following SQL query:Copy
Delete the original server in the subscriptions table
DELETE from pendingnotifications
DECLARE @oldHostname nvarchar(max)
SET @oldHostname = 'Server1'
DELETE FROM Subscriptions WHERE EndpointAddress LIKE ('%' + @oldHostname + '%')
DELETE FROM SubscriptionTags Where Subscription_Id NOT IN (SELECT Id FROM Subscriptions)
Restart SolarWinds InformationServiceV3 on the main Orion server.
Results: In the subscriptions table column
endpointaddress, you should see the new host name and IP in the database entries.
Active Directory login issues
If you experience failures with Active Directory logins, please review the Active Directory login scenarios in the NPM Administrator Guide. You may need to remove an account or account group, and re-add it to Active Directory to successfully login on the new server.
RabbitMQ may require purging
After completing your migration, you may need to complete a purging of RabbitMQ data form the SwisPubSub queue. For details, see this article.
Orion Platform 2016.2 migration and upgrade may not start Syslog and Traps Services
After migrating and upgrading an Orion Platform 2016.2 product (such as NPM 12.0.1 and SAM 6.3), Syslog and Traps services would not start and the Manage Nodes section/option in the Web Console is missing. For more information, see this article.
Engines table must contain just 1 primary poller. If still exists, move the nodes assigned to it to existing poller and remove the redundant one.
Nodes should not be assigned to an old or not existing engine. Use this query to locate the redundant engine:Copy
Locate redundant engine
SELECT NodeId, Caption, EngineId FROM Nodes WHERE EngineID NOT IN (SELECT EngineID from Engines)
Cleanup obsolete entries from OrionServers.
License server and
JobSchedulerHostshould be located on the Primary engine. Use this query to locate these:Copy
Locate license server and JobSchedulerHost
SELECT * FROM WebSettings WHERE SettingName IN ('JobSchedulerHost', 'LicensingMainServerName')
If they are not on the Primary engine, update the
JobSchedulerHostentry and follow the instructions for Migration.exe /promote on Main poller.
Check product licenses are correctly assigned to the existing servers. Click Settings > All Settings > License Manager to open the web-based License Manager. If licenses are not assigned to existing servers, select the license and reassign to a new server.
Make sure the servers can talk to your new main poller. The licensing server should be accessible via NetBios hostnames. If you are unable to ensure the connection on the DNS side, modify the hosts file (c:\Windows\System32\drivers\etc\hosts) with the correct hostname.
After you have successfully migrated your Orion server, ensure that any integration module that links your Orion server to a separate SolarWinds application points to the correct server.
If you have not installed an integration module, do not perform these steps.
DPA Integration Module v10.2 and later
|1. Show all DPA servers integrated with the Orion server||
View all DPA servers that are integrated with your Orion server.
2. Update the Orion server name
Update the hostname in the Orion database.
|Restart Orion services||
Open Orion Service Manager and restart the SolarWinds Orion Module Engine service.
The scripts are not supported under any SolarWinds support program or service. The 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.