Showing results for 
Search instead for 
Did you mean: 
Create Post

How to Migrate Orion to a New Server With Zero Downtime

Product Manager

If you've been using the SolarWinds® Orion® unified IT monitoring platform for more than a few years, it's likely that you've at least once migrated it to a new server. You may have migrated from a physical server to a virtual one, or perhaps you simply needed to migrate to a server running a more modern operating system. Regardless of the reason, you're likely aware that there's a litany of documentation and training videos on the subject. Below are just a few, in case you’re curious.



Now, as many of you have likely discovered during your last upgrade to SolarWinds® Network Performance Monitor (NPM) 12.3, SolarWinds® Server & Application Monitor (SAM) 6.7, or any other product modules released in 2018, support for Windows Server 2012, Server 2012 R2, and SQL Server 2012 were officially deprecated in those releases. You may have stumbled upon that when reviewing the release notes, or during the pre-flight checklist when running the installer.


Deprecation does not mean that those versions aren’t supported with Network Performance Monitor 12.3, Server & Application Monitor 6.7, etc. Deprecation simply means that new versions released in the future are unlikely to support those older operating systems. These deprecation notices were added at the request of customers like yourself, who asked to be provided with advance notice when future versions of Orion product modules would no longer run on older operating systems or SQL database versions. Those deprecation notices serve to allow customers an opportunity to budget and plan for these changes accordingly, rather than find out during a 3 a.m. change window that the upgrade you planned doesn't support your current OS or database version.

While future product module versions may no longer support Windows Server 2012, Server 2012 R2, or SQL Server 2012, that doesn't mean all previous versions are no longer supported at all. In fact, the latest, currently shipping versions of NPM, SAM, and other SolarWinds products are planned to continue to support running on Windows Server 2012 and 2012 R2 for many more years to come. So, if you're happy with the versions of product modules you're running today, take your time and don't rush your OS upgrade or server migration. Plan it appropriately. We'll still be here, waiting with a boatload of awesome new features whenever you're ready to upgrade.


But I digress. Since many of you have planned, or will eventually be planning, to migrate your Orion Platform to Server 2016 or perhaps even Server 2019, this inevitably stirs up painful memories of migrations you have undoubtedly done in the past—whether that was the Orion Platform specifically or some other mission-critical system in your environment. Let's face it, these migrations are typically neither fun or easy. Luckily, we’ll discuss how you can help change that.

Now, over the years, I have performed countless Orion Platform upgrades and migrations. And I, like many of you, have amassed a tremendous treasure trove of tips and tricks for streamlining the process down to an art form. The name of the game here is called downtime, and the less of it you can incur during your migration the sooner you get to go home, and the more you look like a rock star to your boss. What I'm about to show you here is how you can migrate your Orion Platform server with zero downtime!

As I stated above, there is a wealth of information on the subject of migrating the Orion Platform to a new server, and perhaps I overstated it a bit when I suggested that you're doing it wrong. There are multiple different (yet still correct) ways of migrating the Orion Platform from one server to another, and some ways may be faster, easier, or less error prone than others. These migrations typically vary depending upon the type of Orion server role the machine is hosting. This blog post focuses on the main Orion server, but the strategy can apply equally to Additional Polling Engines.

Orion Server Migration Made Easy

Going forward I'll assume you have at least one Orion server running NPM 12.2 or later—that one server being the main Orion server itself. If you're still running NPM 11.5.x, then chances are good you're not planning to migrate directly to Server 2016 or Server 2019 anyway, since 11.5.x isn't supported on either of those operating systems. I'm also going to assume that your Orion Platform server is currently running on Server 2012 or 2012 R2, though this process is equally applicable to those still rocking Server 2008 or Server 2008 R2. I'm also going to assume you have another freshly installed server ready for your Orion Platform migration. Lastly, this document won't be covering database server migrations. If that's what you were hoping for, there's an excellent document on the subject here.

First Things First

As with any good do-it-yourself project, the first order of business is to throw out, or otherwise lose, the instructions. I'm going to be walking you through what I’ve found to be the simplest, fastest, least error-prone manner of migrating the Orion Platform to a new server with absolutely zero downtime. None of those other documents or videos referenced above are going to show you how to do that, so let's just pretend they never existed.

Schedule Your Maintenance Window

While the Orion server should not be going down during the migration, it's always best to plan for the worst and hope for the best. I don't want anyone telling their boss that they decided to migrate their Orion server in the middle of the day because some guy on THWACK® named aLTeReGo told them to do it.

Backup Your Orion Server

Conventional wisdom would tell you that if it can go wrong, it probably will—so be prepared. If your Orion server is running on a virtual machine, take a snapshot prior to the migration just in case. While we won't be messing with that server at all during the migration, it's always good to have a safety net just in case.

Backup Your Orion Database

I can't emphasize this enough. BACKUP YOUR DATABASE! Seriously, just do it. Not sure if the backup from last night completed successfully? Do another one. Everything important is in the database, and with a backup, you can restore from virtually any disaster. If the database is corrupted though and you don't have a good backup to restore from, you may be rebuilding your Orion Platform again from scratch. You don't need to shut down the Orion Platform to take a backup, so go ahead and take another just to be on the safe side. We'll wait.

Need a little extra insurance? Why not give SolarWinds cloud-based server backup a try?

Do Not Upgrade (Yet)

If you’re migrating as part of an upgrade, don't upgrade yet unless you’ll be migrating to Windows Server 2019. It's best to leave the original server fully intact/as-is in the event something goes wrong and you need to roll back. There will be plenty of time to upgrade and play with all the cool new features later. For now, just focus.

Have Faith and Take a Deep Breath

This is going to start off a bit odd, but stick with me and we'll all come out of this together. Start by going to [Settings > All Settings > High Availability Deployment Summary] in the Orion web interface from a web browser on the new machine where you plan to migrate the Orion Platform. Next, click [Setup a New HA Server > Get Started Settings Up a Server > Download Installer Now].

Download the High Availability Secondary Server Installer

That's right, we'll be using the power of Orion High Availability (HA) to perform this Orion server migration. If at this point you're worried that you can't take advantage of this awesome migration method because you don't own an Orion High Availability license, fret not. Every Orion Platform installation comes with a full 30-day evaluation of High Availability for use on an unlimited number of servers. That's more than enough time for us to complete this migration! If you have no need for Orion High Availability, don't worry. The final steps in this migration process include disabling High Availability, so there's no requirement to purchase anything. However, you might find yourself so smitten with Orion High Availability by the end of the migration that you may wonder how you ever managed to live without it. You've been warned!

Begin Installation On Your New Orion Server

Once downloaded, double-click on the Scalability Engines Installer. Depending on which version of the Orion Platform you're running, the Scalability Engines Installer may look significantly different, so I've included screenshots below from both versions. On the top row, you’ll see screenshots from the Scalability Engines Installer version 1.x and version 2.x below that. Regardless of which version you're running through, the end result should be identical.

Connect to Existing Orion Server on Original Server

Select Server Role to Install


Once the installation is complete, the installer will walk you through the Configuration Wizard process. Ensure that all settings entered in the Configuration Wizard are identical to those used by your existing Orion server.

Let The Fun Begin

Now that we've installed a secondary Orion server, it's time to join them together into a pool (aka cluster). To do this, we begin by logging into the Orion web interface on your original Orion server. From there go to [Settings -> All Settings -> High Availability Deployment Summary]. There, you should find listed your original Orion server that you're logged into now, as well as your new Orion server that you just installed in the steps above. Click the “Set up High Availability Pool” button next to the name of your new Orion server.

Setup High Availability Pool.png

Now, if both your existing Orion server and the new server you'll be migrating to are located on the same subnet, you might be prompted to enter different information within the HA Pool creation wizard. It's also important to note that if you're currently running Orion Platform 2017.1 or earlier, it will not be possible to perform this zero-downtime server migration, unless both your existing and new Orion servers are located on the same subnet.

Same Subnet Migration

If both your existing and new Orion servers reside on the same subnet, you’ll be prompted to provide a new, unused IP address on the same subnet as your existing Orion server. This virtual IP (VIP) will be shared between these two Orion servers, as long as they remain in the same HA Pool. The purpose of the VIP is to route traffic to whichever member in the pool is active. If you don't have intentions of keeping HA running after the migration, this IP address will be used only briefly and can be reclaimed at the conclusion of the migration. When you're done entering the IP address, click “Next”.


Migrating to Server in Different Subnet

If you're migrating to an Orion server on a different subnet than your existing one, then the HA Pool creation wizard will prompt you to provide a virtual hostname rather than a virtual IP address. This name helps ensure users are directed to the “active” member in an HA pool when accessing the Orion web interface whenever failovers occur. If you don't have intentions of keeping HA running after the migration, you can enter anything you like into this field. Once you've populated the “Virtual Host Name” field, click “Next.”

Pool Properties.png

On the “DNS Settings” step of the HA Pool creation wizard, select your DNS server type or choose “other” from the “DNS Type” drop-down menu if you don't intend on keeping HA running after the migration. If you choose “other,” you can populate any IP address and any DNS zone (even one that doesn't exist) into the fields provided—these values will not be used unless you plan to integrate Orion High Availability with a non-Microsoft and non-BIND DNS server in the future.


When complete, click “Next” to proceed, review the “Summary,” and click the “Create Pool” button to complete the HA Pool creation process.

Ready, Set, Cut-over!

From the Orion Deployment Summary [Settings > All Settings > High Availability Deployment Summary], select the HA pool you just created. On the right side, click the “Commands” drop-down menu and select “Force Failover.” This should initiate an immediate failover from your old Orion server to your new one. Note that while the cutover time for polling and alerting is typically just a couple of seconds, it may take the Orion web interface a minute or so before it's fully accessible. Unless you were accessing the Orion Web Console using the VIP you assigned earlier, you’ll need to change the URL in your browser to point to the IP address of the new Orion server or the VIP to regain access to the Orion web interface once you've initiated the failover.

Fore Failover.png

Verify you're cut over to the new server by looking at the pool members listed on the Orion Deployment Summary, specifically their state or roll showed just below their names. Your old Orion server should be listed as “Standby,” and your new Orion server should display as “Active.” Congratulations! You've just completed a successful Orion server migration with zero downtime!


The following steps should be completed within 30 days if you don't currently own or have plans to purchase Orion High Availability to provide continuous monitoring, redundancy, and near-instantaneous failover of your Orion server in the event of a failure. Don't forget that Orion High Availability also helps you maintain that your Orion Platform’s 100% uptime every month when Patch Tuesday rolls around. (Patch Tuesday… or, you know, when Microsoft releases its latest round of operating system hotfixes, all of which inevitably require a reboot.)

Shutdown Old Server

You should start the cleanup process by shutting down your original Orion server. It served you well, and we all know how hard it is to bid a final farewell to such a loyal friend, but its time has come. If you're not immediately planning to destroy the virtual machine or de-rack your old Orion server, you may first want to consider changing its IP address if you plan to use it on your new Orion server. This will ensure that if the old Orion server is started back up, it won't cause an IP address conflict and wreak havoc on your network monitoring. Once you've changed the IP address, resume with shutting down the server before proceeding with the next steps.


Remove The Pool

From within the Orion web interface, navigate back to the High Availability Deployment Summary by going to [Settings > All Settings > High Availability Deployment Summary]. Click on the name of the Pool you created earlier in the steps above. From the “Commands” drop-down menu on the right select “Remove Pool.”


Reclaim The Original Orion Server's IP Address

Last, but certainly not least, you may want to reclaim the IP address of your original Orion server by assigning it to your new Orion server. This is simply a matter of logging into the Windows server via RDP (or etc.) and opening the Network Control Panel. I prefer to go to the “Run” command and typing “ncpa.cpl” and <Enter> to open the Network Control Panel without needing to navigate around Windows. Once you've opened the Network Control Panel, right-click on your network interface and select “Properties.” Within the interface properties, select “Internet Protocol Version 4 (TCP/IPv4)” and click “Properties.”

Network Control PanelInterface Properties

Update the “IP Address” field by entering the IP of your original Orion server, then click “Advanced.” In the “Advanced TCP/IP Settings,” you’ll find the Virtual IP Address you configured earlier in the steps above—you should be able to safely remove this now. To do so, simply select it by clicking on the IP address with your mouse and then click the “Remove” button. Then, click “OK” on each of the three windows to save your changes.

TCP/IP PropertiesAdvanced TCP/IP Settings

Update DNS/Machine Name

Do not rename the server itself in Windows. If you have users who are accessing the Orion Web Console via the original server’s name, the best and easiest method of ensuring those users can now access the new server is to create a DNS C-Name that points to the new server. It's always a good idea to have a layer of abstraction between what name end users type into their browser and the name of the server itself. This can help ensure that you can easily redirect those users later, should you want to add an Additional Web Server or re-enable High Availability. To accomplish this, we are going to create a DNS CNAME record for your original Orion server's name that points to the new Orion server. In this example, I'm using Windows DNS, but the same principle applies for really any type of DNS server.

From the DNS Control Panel on your DNS Server, expand “Forward Lookup Zones” and right-click on your domain name and select “New Alias (CNAME).” In my example below, my previous server's FQDN (Fully qualified domain name) was “solarwinds.sw.local” and my new Orion's server name is “pm-aus-jmor-04.sw.local.” In the “Alias name” enter “solarwinds.” The “Fully qualified domain name” field will automatically populate with the alias and domain name. In the “Fully qualified domain name (FQDN) for target host” field, enter the FQDN of your new Orion server and click “OK” to save your changes. Lastly, find and delete the ANAME “Host (A)” record for your old Orion server.

DNS Control PanelAdd New Alias (CNAME)

While this undoubtedly looks like a lot of steps, the process is actually fairly straightforward and I completed it in less than an hour. Now, obviously your mileage may vary, but regardless of how long it may take, there's no simpler way—for which I'm aware—that will allow you to migrate your Orion Platform to a new server with anywhere close to zero downtime. Hopefully, this process will save you a fair bit of time and frustration over the previous methods referenced above. If you have any tips and tricks of your own that have simplified your Orion server migrations, feel free to post them in the comments sections below—we'd love to hear them!

The SolarWinds trademarks, service marks, and logos are the exclusive property of SolarWinds Worldwide, LLC or its affiliates.  All other trademarks are the property of their respective owners.

Level 14

Nice slide over.  Thanks.

Level 10

I actualy tried something similar in the early days of HA , migrating from 2008 R2 to 2012 R2 but it did not work as i was getting an error that the HA servers are running diferent OS and the wizzard didnt complete. I abandon that iddea and just created new 2012 R2 server and used the long procees as esplained in the oficial migration.

Now i was about to do the same long process this weekend to migrate to 2016 but since you say you have good result with this i will give it a try this Sathurday.

I also have 2 aditional webserver, any ideea if i will need to perform any action on these?

Product Manager
Product Manager

This method would not have been possible using Orion's Failover Engine, as it reqired that all members in a cluster be identical. E.G. same hardware and software versions. Orion High Availabiliy has no such limitation, and therefore can be used in a variety of different ways that the Failover Engine could not, such as migrations.

Level 10

So i activated a 30 day trial HA licence yestarday and did the procedure untill the step to fail to the new server. Now this morning i found the 30 day trial licence with an expiration date of yestarday so i am no longer able to complet the process.

Got a trial licence extension from support:

Request for a temporary License Key - SolarWinds Worldwide, LLC. Help and Support

The migration worked 90% as described above there were only 2 smal problems and 1 medium :

1 Smal. On the new server the netflow stoped working. When i rerun the config wizard for the Db part it no longer gives the option to store Netflow on a remote server and it want to store it localy . In the notification part i get  : "FSDB is not configured. Can't receive flows until FSDB is configured" Lucly for me i wasnat planing on using the main pooler for Neyflow; the 3 aditional APE i have are comunicating jsut fien with the NTA DB.

2 Smal. In the recover the IP from the OLD server i needed to do 1 smal extra step: after removing the HA pool i also had to Delete the old server from the High Availability Deployment Summary

I also tried the exact same process for replacing an APE and it worked perfectly. In this case the Netflow remote storage setting were still available and i had 0 downtime in netflow colection.

1 Medium. : in application monitors i get under Aplication detail There was an error while rendering resource with id 1172. The resource ID is not always the same but there are only 3 or 4 ID spred aroud 100 diferent aplications. The components inside the aplication still work, they pull date and the alerts base on them work. The problem apears when you want to edit the actual aplication because the edit button is under Application detail. If you use the buton in the uper left cornet to edit the aplication you get an error :

The formatter threw an exception while trying to deserialize the message: There was an error while trying to deserialize parameter The InnerException message was 'Member '_compareInfo' was not found.'. Please see InnerException for more details.

You would think that is similar to Unexpected website error when editing nodes in Orion Platform - SolarWinds Worldwide, LLC. Help and ...  but i made sure i have .NET 4.7.2 on all servers.

Level 9

aLTeReGo    Guess I'm a little confused by the process or maybe the wording.  I understand the idea of setting up a secondary server, but where do you actually upgrade Orion and all the SW apps? Or, is this just instructions for migrating to a new server/new OS and not upgrading Orion?

Product Manager
Product Manager

This blog post is about migration, not upgrading Orion. Once you've sucsesfully migrated to your new servers, you can being upgrading your envionment.

Product Manager
Product Manager

Yikes! That should never happen. Is it possible the time/date on the other member was signifigatly off from the original poller? If you're in a bind, please direct message me and I will provide you with a 30 day temp key for HA.

Nice! Might come in handy for the next migration task at my clients.

Had the same issue a few days ago with an NCM PoC installation. When I installed an additional polling engine trial, the license store somehow got corrupted, happened on 2 out of 3 installations. Still need to find out what exactly happened.

Level 9

I have client initiated agent installed on Linux and IBM servers. Do they point to the server by name or IP?  Do I need to go through each agent to update the name/IP so it points to the new server name/IP?

Level 10

Excellent write-up aLTeReGo​!  Our team occasionally runs in to one-off  issues using the traditional app migration method.  We'll certainly look at this method to reduce the chances of something "borking"  

Level 12


How would this work if they already use HA or does this process assume that HA is not currently in use? I could see killing the existing pool and creating the new one, but didn't know if that would cause any troubles under the surface.

Best Regards,

Derik Pfeffer

Loop1 Systems: SolarWinds Training and Professional Services

    LinkedIN: Loop1 Systems

    Facebook: Loop1 Systems

    Twitter: @Loop1Systems

Product Manager
Product Manager

The process actually wouldn't be too much different. The only real difference is that you'd start by breaking your existing pool and shutting down or destorying that VM before proceeding with the steps above. Obviously, since you own an HA license already, you would skip all of the 'clean-up' steps. That would get you half way there with one server on Server 2016 (or Server 2019) and one still running Server 2012 (or 2008) in the same pool. With that said, you would need to repeat the process again to migrate both members to a newer operating sytem. While it will take twice as long to complete, because you're migrating two members, you'll should still be able to complete the entire process from beginning to end for both members with zero downtime.

Level 9

I understand now  Thank you for the post and responding.

Level 10

We do not have the HA license right now, but one step that is included when changing the IP/Hostname is the step about updating the server name in the database.  This is part of step 7 on this link:

Migrate SolarWinds Orion products to a new server with a new IP and hostname - SolarWinds Worldwide,...

Update references to the old server and remove HA entries

With this method, during the cleanup of HA, do you need to do it?  Or does the HA process handle it? 

I am about to do the switch to server 2016 and this looks like a great way to do it, and I plan to use it.  But, the hostname of the server will be changed, but the IP will be reused.  I am also moving the SQL database over to SQL 2017 from 2014 on another server.

Product Manager
Product Manager

If you encounter issues where you are unable to recreate the HA pool after migrating, then yes. You should truncate the HA tables and restart the HA service to proceed with the HA pool creation.

This query removes the HA entries. They are automatically repopulated when you restart the HA service.

truncate table HA_FacilitiesInstances
truncate table HA_PoolMemberInterfacesInfo
truncate table HA_PoolMembers
truncate table HA_Pools
truncate table HA_ResourcesInstances

Level 11

I'd like to report that this method worked Very well for me to migrate a new primary with same subnet, decommission original, then remove original,  then use New Primary to migrate another New Standby Primary on different subnet.  Thanks so much for taking the time to type this out. The only thing we had a hiccup with was when it came time to choose between DNS "Host(A)" record or use "New Alias (CNAME)".  We followed instructions to create cname pointed to virtual hostname, but then when we failed over we received server communication error in upper right corner, resources were missing, and main toolbar at top was missing, but when we deleted that and used Host(A) record instead, failover was successful.

Level 11

Kudos, Well done, great write up.  What verison of sam would one need to be at might be helpful as some folks split NPM and SAM don't ask me why but folks do and I understand it.

Product Manager
Product Manager

SAM 6.3 would be the minimum version required to complete the steps outlined above. Really any Orion Platform 2016.2 module or later would work.

Orion Platform 2016.2 compatible products - SolarWinds Worldwide, LLC. Help and Support

Level 9

What would be the process in a scenario with multiple pollers and additional web server? We have load distributed across multiple pollers with many elements on each of them.

Just want to understand the flow in a scenario from a perspective of the ordering, additional evaluation software to be obtained other that HA engine.


Product Manager
Product Manager

The process for Additional Polling Engines is essentially identical to that of the main poller. Simply rinse and repeat. Additional Web Servers have no unique configuration settings, so no migration is necessary. Simply stand up another on a new server and direct user traffic there, either by taking the same IP address as the old one when you're done, or updating the DNS entry uses use to access the Additional Web Server. If you have multiple Additional Web Servers it's best to frontend them with a load balancer which makes this process even easier.

Level 12

Ran into an issue, First step, download the software.  I get a 404 not found.  What is the file name so I can pull it from the server or at least search for it.

Product Manager
Product Manager

Alternatively you can obtain the same installer by going to [Settings > All Settings > Polling Engines]


Similarly, you can also find it under [Settings > All Settings > Web Console Settings]


Level 12

Same results. Appears that it was never installed on this server.  What is the installer file name, I can run a file search to see if it actually exists.  I don't see sapi in IIS, hence the 404.

Product Manager
Product Manager

The file is named 'SolarWinds-Orion-Installer.exe'. It should be located in 'C:\ProgramData\SolarWinds\Installers'

Level 12

Found it right where you said.  Apparently the web interface was not created during the upgrades.

Level 11

I have the same question as jkcy​, as we use the agents extensively in our environment. Wouldn't doing this method break connectivity from the agents? I'd imagine you'd have to redeploy the agents after this? 

Product Manager
Product Manager

Negative. The agents are HA aware. Provided any 'Active' agents can reach the new Orion server's IP address when you perform the failover, then there is no need to redeploy agents.

Level 11

Even if you dissolve / remove HA at the end and re-claim the old servers IP on the new one?

Product Manager
Product Manager

Hmm. That's a fair point. This would require a hop, skip and a jump to ensure the Agents know about the new IP address. This would mean failing over to the new Orion server, changing the IP address of the old server to something temporary, failing back to the old server, changing the IP address of the new Orion server to the original IP address of the old server, then failing back before dismantling the HA pair.

Each time services are restarted on the Orion server, the Agents download a manifest we call 'Service Directory', which includes the list of all IP addresses the polling engines the agents are allowed to communicate with. Provided the agents get this update properly and you don't just change the IP address of the Orion server without it having the ability to notify the agents of this change, you should be fine. Hence my hop, skip, and jump technique above.

Level 8

A troubleshooting step for those doing this for the first time like me.  I ran into a slight issue with the wrong version an installer not being available from the primary poller.  The installation had trouble downloading the correct version, so I had to manually download the file given the link found in the installation log and placed it into the Installer folder.

Installation logs: C:\ProgramData\SolarWinds\Logs\Installer.

Installer folder: C:\ProgramData\SolarWinds\Installers

After resolving that, everything was very smooth.

Level 10

Hey aLTeReGo​ thanks for the write up and it works very well for having no down time. 

I'd also like to add if you are moving to a new OS due to the cortex issue make sure you put the buddy drop in place before you switch to your new poller, I found out the hard way....​

Level 9

This is a great "How To", however i'm running into a little trouble removing the pool. When I select Remove pool the following error is showing "The pool cannot be deleted. it wants the original server to be active to delete the pool. Any help would be great. 1182019.JPG

Level 9

What is buddy drop?

Level 10

Buddy drop are files provided by Solarwinds to fix a problem. 

Level 9

Doing more testing I found that now if I shut down the original server I loose access to the web interface. I'm thinking something in the HA pool did not get configured correctly. I'm going to remove the new server from the pool and start over. I will update with a status once this is complete.

Level 9

This is a great document and I took the approach to test our upgrade in development.  The HA worked and I was able to complete upgrade so the main poller (MP) was replaced with a new WS2016 system. 

My Orion setup has 1 MP (WS2012, Orion 2018.2), 4 APE (WS2016), 1 AWS web server (WS2016) and DB is on a SQL 2012 Always-On.

My objective is to upgrade the MP from WS2012 to WS2016 first, then move DB to a SQL2016 cluster.

Current state:  MP (WS2016, 2018.2) and SQL is still 2012

There are couple things I'd like to point out:

1. NTA is reported broken from the console even though the NTA service is still running. Not sure if this is just my setup.   SolarWinds Support recommended me to uninstall. However this is impossible until the DB is SQL 2016 as the new installer requires WS2016 and SQL2016. My Orion version was from September 2018 and the new one was introduced in December 2018.  I tried with the installer from my console hoping it would stay with the installed version.   Unfortunately it still reach out to SolarWinds to grab the latest version.  SW's approach on this makes things hard and causes additional works during this process.

2. At this state I would like to add a new Standby node to the Main Poller.  This is impossible again, at least until the DB is upgraded.  I downloaded the installer from the HA page and it still reaches out to SW for the latest installer. Bummer!

Lessons learned: Should upgrade the systems to meet the min requirements before the installer makes them hard requirements. 

We were on tight production project schedule and did not have the slot to add this upgrade project.  It was like 6 months from the time we heard the new requirement to when it is enforced. It's quite short in a enterprise production environment.   I really hope SolarWinds to consider a longer roadmap for this type of changes.

Product Manager
Product Manager

Have you tried accessing the Orion web console via the IP address of the new Orion server or the VIP?

Product Manager
Product Manager

Out of curiosity, which version of the Orion Platform are you running?

Product Manager
Product Manager

We have tried reproducing this issue internally without success. If you're willing, please send me your SolarWinds.Administration.Client.log and Solarwinds.Administration.log files so we can determine why this occurred.  

Level 9

Where can I see this manifest 'Service Directory' from client machine (Windows and Unix) or if they are logged on client/server sides? I'd like to validate that during my tests. Thanks.

Product Manager
Product Manager

Service Directory logs are located under %ProgramData%\Solarwinds\Logs\Orion\ServiceDirectory

Level 10

I've gotten all my APE's moved to the new OS, but I'm having problems with my main poller, both servers are showing down on the HA page, so the pool stays grey all the time, any suggestions on troubleshooting the HA status of the main poller?

Product Manager
Product Manager

Are all services running on at least one host? Can you post a screenshot of what you're seeing? Is each of the Orion servers managed by Orion as nodes through the Agent? If not, please do so.

Level 10

Yeah aLTeReGo​ all services were running, I couldn't figure it out, so I gave up and called support, and after some service(s) were stopped and some DB queries ran it was resolved and all is well.

Level 8


I have setup the HA pool and had to edit the bindings on the old server to accept the connections on the VIP?

I just logged into the new server and checked IIS and found that the Solarwinds NetPerfMon site is in a stopped state. Is this by design or should it be running?

Product Manager
Product Manager

When Orion initially configures IIS it is bound to all IP addresses on the server. If there have been modifications to the bindings (not uncommon when moving to HTTPS) then you will need to adjust those bindings appropriately to allow IIS access from the VIP. Nice catch matnetmin​!

Level 8

thanks aLTeReGo

Should the standby server have the NetPerfMon website in a stopped state also?

Product Manager
Product Manager

matnetmin  wrote:

thanks aLTeReGo

Should the standby server have the NetPerfMon website in a stopped state also?

No, IIS should be running on both primary and secondary servers of the main Orion HA pool.

Level 9

Great HowTo aLTeReGo​ -

We're embarking on the migration from 2012R2 to 2016 for our production environment very soon, and we're re-using the same IPs/Hostnames for the new WS2016 servers. I'm being very cautious, since I don't have a UAT environment to test in first.

Current config is:  One HA Main Pool (different subnet config, so virtual hostname) and two APEs.


Burning questions I still have for using your method in an existing HA environment (have also read the official doc for this method​ of re-using the same IPs/Hostnames):

1. When you say "start by breaking the pool, removing one of the members that's running an older OS", what is the correct/safe way to do that? Just highlight the Main Pool, and choose Remove Pool, then shutdown the old Standby server?

2. How do we handle deactivation/reactivation of product licenses using this method?  The official docs always refer to releasing licenses before standing up the replacement server. Is that necessary with this method?

3. When replacing an APE with a newer one with the same IP/hostname, do we shutdown the old one but leave the object in place within Orion, thus preserving the Polling Engine location for monitored Nodes, and as the new one comes up, Orion will see it just fine?


Thanks again for any additional wisdom you can provide for those of us already in an HA production environment and are a bit squeamish about performing a conversion on this scale. You can also just tell me to go... get support involved, and I'll completely understand 8^).