cancel
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.

Index

Deprecation

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.

pastedImage_7.png

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.

Preface

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
pastedImage_1.png
pastedImage_2.png
pastedImage_4.png
pastedImage_5.png
pastedImage_9.png

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

pastedImage_0.pngpastedImage_1.png
pastedImage_2.pngpastedImage_1.png

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”.

pastedImage_6.png

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.

pastedImage_0.png

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!

Clean-up

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.

pastedImage_1.png

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.”

pastedImage_6.png

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
pastedImage_33.pngpastedImage_34.png

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
pastedImage_37.pngpastedImage_39.png

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)
pastedImage_0.pngpastedImage_2.png

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.

199 Comments
Product Manager
Product Manager

gperkins  wrote:

While trying to upgrade a Win2012 server running Orion 2017.1 and several other SolarWinds modules (all in need of upgrade) I attempted to use the blog. After several false-starts (needing resolution with the help of Technical Support) I finally got HA working and a copy of my existing Orion on a new Win2016 server. However, then when it came time to re-IP and remove HA in order to upgrade, it didn't make sense. Technical Support had me failback to the original Win2012 server while I upgraded on the Win2016 server. Then schedule an outage to re-IP, re-name, and re-license. So, contrary to this article's title, I was NOT able to perform an upgrade with zero downtime. This article only will work (and then probably you will have several hiccups) if your intention is to ONLY upgrade the OS.

This document does not describe upgrades, rather migrations.

Level 9

Are there any concerns with this breaking netflow? Anything I need to watch out for? We'll be migrating from 2012 to 2016 (new IP, different subnet) and we're currently using NTA 4.2.3 with the database stored on a separate server. We'll also be migrating SQL (NTA database will be on the same server after we upgrade the module) after the Orion migration is complete. I just don't want to break anything unexpectedly in the meantime.

Product Manager
Product Manager

msinger​, with NTA it's less of a migration than it is cutting lose the old flow storage database and starting anew on MSSQL. There is no ability to migrate the existing historical flow data in the Flow Storage database to MSSQL.

Level 16

I have some questions w.r.t to the steps required to migrate the setup from old server to new server with new hostname and IP. This includes both Solarwinds main poller and DB server.

1. First i would have to make new servers ready and install the Solarwinds application and DB on respective VMs. Config wizard will not be run for Solarwinds application.

2. Deactivate the licenses on old VM.

2. take backup of existing DB.

Now after this i have a question about below point.Where do we need to run this? And should be backup of DB be taken after this if restore is required on different server?

pastedImage_0.png

Bit confused so if anyone can guide me on exact steps, it will be great...

Product Manager
Product Manager

Are you running HA today? If not, then this step is not at all applicable to you.

Level 16

aLTeReGo​ No m not using HA...

In that case, will below steps be fine?

1. Restore the old DB to new DB... keep the old db also in tact till evrything is working fine on new one.

2. install Solarwinds on new VM without running config wizard

3. deactivate licenses on old setup and save it

4. then run the config wizard on new Solarwinds and connect to the new DB where data is already restored

5. apply the licenses on new setup

Any other steps i would need to follow or be aware of?

Level 16

just to confirm, will these steps be safe to go with it...?

Product Manager
Product Manager

That's pretty much it. Just ensure you keep a backup copy of the database just in case.

Level 8

Can't seem to get past this error. I have the same products and versions on both pollers.

pastedImage_0.png

Product Manager
Product Manager

How was Orion installed on the 2nd server?

Level 8

02 is an additional polling engine, It was set up by using the installer from the "Polling Engines" page.

Level 8

I had this same issue. It turned out that VNQM wasn't really installed on my new server, even though it said it was. If you go to uninstall programs in Windows, you should see that one of your modules isn't listed there on the new poller.

I copied the msi and config file from the old server to the new server and ran the msi, and then the configuration wizard on the new server. That got VNQM installed.

Then I followed some HA troubleshooting articles to clean up the database and run the configuration wizard again to get the new server showing up in the HA configuration page.

Level 8

tsleck@ucare.org That could have caused the problem. Uninstalled SW and Reinstalled on the new HA polling engine and that fixed the issue. Thanks!

Perform a fresh Orion installation

https://support.solarwinds.com/SuccessCenter/s/article/Perform-a-fresh-Orion-installation-on-the-sam...

Level 7

I don't see "High Availability Deployment Summary" or "Download installer now" from All Settings, Polling Engines.  How do I go about getting the installer to continue with this process?

Level 7

I can't find the installer in any of these locations

Product Manager
Product Manager

What version are you currently running?

Level 10

Hi #alterego ,

How do we go about the APE migration once we have migrated the main poller from Windows server 2012 to 2016 using HA method ?

Product Manager
Product Manager

The process is rinse/repeat for Additional Polling Engines.

Level 12

pastedImage_0.png

I get this message when trying to remove the Main Pool. The crossed out server is the original server and is the standby and has been shutdown. I also tried when it was still online and got the same error.

Any suggestions?

Product Manager
Product Manager

Is it possible that you're running either NPM 12.0.1 or 12.1?

Level 7

I've run unto the same situation. I'm running NPM 12.1

Level 12

Yes NPM 12.1

Product Manager
Product Manager

I have managed to reproduce the issue internally and it seems there are additional steps required for 12.0.1 and 12.1 due to the license store residing on the primary main poller. In NPM 12.2 the license store was moved into the database to prevent this issue from occurring. Thank you for point this out. I have updated the post above to reflect this.

There are some additional steps required for 12.1 which are outlined below.

1. Reclaim your license keys from the Original server by deactivating them. If the server no longer exists, work with Customer Service to have them reset for you.

2.  On the new Main Poller you're migrating to, open a command prompt and issue these commands.

c:

cd "\Program Files (x86)\SolarWinds\Orion\Licensing"migration.exe /promote

If successful, the tool will return the following message:

C:\Program Files (x86)\SolarWinds\Orion\Licensing>migration /promoteAre you sure you want to designate 'WIN-9BJA0MDF9I8' as the Main Poller with the active license store (Y/N)? y'WIN-9BJA0MDF9I8' is now designated as a Main Poller with the active license store.!!! IMPORTANT !!!On *every* machine connected to the Orion database, you must now restart:A) SolarWinds Orion Module Engine (Windows Service).Until completed: 'WIN-9BJA0MDF9I8' will refuse license management connections.Until completed: machines will connect to 'WIN-OLDMACHINE' for license details.B) Restart all Orion websites (where applicable) using *IISRESET*.Until completed: websites will connect to 'WIN-OLDMACHINE' for license management.

3. Follow the steps outlined in the message above, resetting services and websites.

4. Open the license manager from the Orion web interface and activate all license keys.

5. if you have any stacked polling engines, do not forget to assign those licenses appropriately

6. Clean up Engines table in the database table, removing any references to the old main Orion server

Level 12

So somewhere I guess I didn't do something right.

I deactivated the licenses while the old main was primary, then forced failover, ran the /promote, restarted services and it failed over to the old main. ( I assume that I should have broke the pool before restarting serivces)

I seem to be stuck over on the old main.

I can't delete the pool because I'm not on the new main, and I have a message saying that HA pool license is required...I shutdown the old main and I can't get the services started on the new main.

Help please. I do have Case # - 00421442 opened for this.

Product Manager
Product Manager

Prior to restarting services the HA pool should have been broken. This can be forcibly done by running the following SQL query.

truncate table HA_FacilitiesInstances

truncate table HA_PoolMemberInterfacesInfo

truncate table HA_PoolMembers

truncate table HA_Pools

truncate table HA_ResourcesInstances

Once the pool is broken, shutdown the old main Orion server, start services on the new main poller, activate your license keys.

Level 12

Performed as instructed, Services on New will not start with the exception of the Orion Module Engine service.

Product Manager
Product Manager

I would recommend verifying all entries in the engines table are accurate and up to date. Remove any entries for servers that no longer exist, and ensure there are entries, and that they are correct, for any servers which should exist in the newly migrated environment.

MVP
MVP

jamison.jennings If HA kicked in when failing back to the old main, and you've cleared out the HA tables, updated the Engines table, etc. also make sure the SolarWinds services aren't "Disabled" on your new main server.

Level 7

I thought I had everything setup and when I attempted fail-over it failed.  I opened a SW ticket and after several hours of re-installing components on my standby and running the configuration wizard several times, the tech said I could not use this HA method.

he pulled this log entry:

2019-11-12 20:24:19,480 [55] (8) ERROR SolarWinds.Orion.Web.UI.EvalBanner - (null)  Error while loading eval information.

System.ServiceModel.EndpointNotFoundException: There was no endpoint listening at net.tcp://localhost:17777/SolarWinds/InformationService/v3/Orion/Streamed/certificate that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.

So I feel I am back at square one to plan a different approach to migrate.

Product Manager
Product Manager

The error you describe could occur for a variety of reasons. E.G. The SolarWinds Information Service failed to start for some reason. Support should help you identify the cause. This could also be a licensing issue. Regardless of the reason, this is hardly the only way to migrate your Orion to a new server. It's the only way to do so with zero downtime, but the other methods don't exactly require copious amounts of downtime when properly planned and efficiently executed.

Since you're encountering an unusual amount of difficulty with zero downtime migration, I recommend doing a more traditional migration. Install the latest versions of product modules on a new server with a 30 day evaluation, but cancel the Configuration Wizard when it launches. Next grab a fresh backup of your Orion database and restore it to your new SQL server, if you're combining this with a SQL server migration. Next, run the Configuration Wizard against the database on the new SQL server. Lastly, reclaim your licenses from the old server and activate them on the new server before shutting down the old server. The whole process from beginning to end should probably take a couple of hours.

Level 12

I finally got through my issue today while on the phone with support. The new main was still "stuck" thinking it was a Standby server.

After a registry adjustment and another config wizard run, it was all good to go.

Level 7

I had a few glitches during this process.

1) When the configuration wizzard ran it would not let me connect to NTA on another server.  It wanted to create it's own instance on the new server.  Support had me continue on and i still have to fix the NTA issue.  No flow data till it's resolved.  They recommend uninstalling just NTA and reinstalling the same version.  Then i should get the option for the legacy db connection information.. fingers crossed.. haven't tried this yet. Hopefully 4.2.3 supports os 2016 for me to do that.

2) In the instructions after the pool is removed.. it moves right on to changing the ip's.  Nothing about also deleting the old server object that now shows down and then disabling High Availability for those of us that dont own HA.  I assume at this point it's safe to proceed with those two steps?

So happy I found this process Thank you for the write up

Velma

Product Manager
Product Manager

vharnum  wrote:

2) In the instructions after the pool is removed.. it moves right on to changing the ip's.  Nothing about also deleting the old server object that now shows down and then disabling High Availability for those of us that dont own HA.  I assume at this point it's safe to proceed with those two steps?

Yes, it is safe to proceed. If you're not planning to keep HA, you can run the following SQL query after migrating to remove all HA related configuration from the database.

truncate table HA_FacilitiesInstances

truncate table HA_PoolMemberInterfacesInfo

truncate table HA_PoolMembers

truncate table HA_Pools

truncate table HA_ResourcesInstances

Level 12

Well, Good to go may be relative....

I've had no alerts since the day I created the HA pools,

NCM jobs also don't complete.

Suggestions?

Product Manager
Product Manager

jamison.jennings  wrote:

Well, Good to go may be relative....

I've had no alerts since the day I created the HA pools,

NCM jobs also don't complete.

Suggestions?

Are the alerts not triggering, or you're not receiving notifications? What you're describing with both alerts and NCM jobs could be related to an IP address change in an environment with strict ACLs or Firewall policies.

Level 12

I just figured out the alert problem. The alerting service v2 wasn't installed...go figure. Re-ran config wizard to fix that.

Post migration I changed back to my original IP's so it's not an IP/ACL issue.

Level 7

Hi.  I'm at the step where I begin the Set Up High Availability Pool process, but the page is asking for a Server name, not a VIP, even though both servers in the HA pair are in the same /24 subnet.  Has anyone else seen this?  I read about the workaround but I'm curious why it doesn't see the pair in the same subnet.

Product Manager
Product Manager

When looking at each invidual server under the 'High Availability Deployment Summary' does the IP address of each server look to be correct and in the same subnet?

Level 7

One of the excellent SolarWinds engineers figured it out for me.  One of the IPs was statically assigned to its server, while the other was a DHCP reservation.  Great work on his part to spot that.  Thanks for your quick response!

Level 10

I've been evaluating various methods of migrating/upgrading my SolarWinds environment. I have a primary and one APE (Windows 2012) with a standard set of Orion products (Orion Platform 2018.2 HF6, WPM 2.2.2, SRM 6.6.0, NCM 7.8, CloudMonitoring 2.0.1, NPM 12.3, DPAIM 11.1.0, VMAN 8.2.1 HF1, UDT 3.3.1, SAM 6.7.0, NetPath 1.1.3).

I've got two new Windows 2019 servers and the plan is to migrate so we can upgrade to the latest versions of all the tools. We were looking at the HA option but since short downtime isn't much of an issue it seems installing HA and then untangling it after the fact is an extra piece we really don't need to worry about.

We're going to leave the new servers with the new hostnames/IPs after migration. So my question is whether the installation path should be to install the same versions of the tools first, bring everything up to make sure all is well and then upgrade, or to simply install all the latest versions using the online installer on the new servers? The upgrade/migrate documentation to me seems a bit unclear on that subject, or at least that it doesn't explicitly say one way or the other which is better/recommended (unless I missed it).

On one hand I'd think installing latest versions should be a safe option as we'll have a backup of the DB and if anything goes sideways when running Config Wizard we should just be able to restore the DB from backup, rerun config wizard on "old" servers, and start them back up.

Any thoughts on the best upgrade process in my scenario?

Level 12

So if/when I upgrade (which will probably be sooner vs later).  What about the polling engines, do they also need to get upgraded to the higher OS?  And the SQL server?

Product Manager
Product Manager

The same process can be followed for Additional Polling Engines but it might be easier to just create new ones and move your nodes over to them.

Level 12

Thanks.  And the same for the Database server?

Level 10

Regarding APEs, As someone who just did this, I agree with aLTeReGo. In hindsight it would be easier to just create new APE(s) at the new version and just move nodes to them.

Regarding the DB server, I'd do that migration and/or upgrade first to get to supported OS and SQLServer versions. I did mine in advance, separate from my Orion/Poller migrations, just to be sure to segregate all activities to make troubleshooting easier. DB is relatively easy as your DBA can stand up the new server and DBMS in advance, restore a DB backup there, and you can run the config wizard to repoint Orion to the new DB. The documentation is directly on point.

Migrate the SolarWinds Orion SQL database to a new server

Level 12

Is it possible to stand up all of the hosts you need, using a one to one build, then on the day of upgrade, shutdown all of the old hosts, re-ip/rename them to something, then take your new hosts and name them the old names and IPs from original installation, then install/upgrade fresh?

I like HA idea, I think it is solid as a possibility, but, if I don't have to do a set of steps then I want to avoid it...the way I see it, I have to rename/re-ip everything anyway, and I also have to upgrade anyway, so just want to see if it is going to be possible on new 2019 servers to install/upgrade

Level 10

In short, yes. The first migration/upgrade I did with Orion, maybe 18 months ago, I kept the same names and IPs but they were new servers so I did the rename/re-ip dance. I considered doing that in this most recent upgrade but for other internal reasons I decided to go with new names/new IPs. That process was also relatively simple and painless (I just have a main poller and one APE). Had maybe an hour or so of downtime. Obviously the devil is in the details at your shop, but I was able to get our new pollers up and running without the need for very many changes except for some ACLs and trap destinations hard-coded on some network gear, and I got them updated in advance.

My thought process was very much like yours. I considered the HA solution, but since we don't run it currently and would have had to remove HA afterwards, I decided taking a little outage was not a big deal in lieu of additional steps of installing/removing more software components. As I think I noted earlier in the thread the only difference I'd take in approach would be creating a new APE from scratch at my new version and just migrating the nodes over to it via the Orion functionality. I used the steps in the migration guide to update the Engines and OrionServers tables to migrate the APE and hit a bump somewhere. Support was able to get me up and moving without much difficulty though. In hindsight I'd just do what aLTeReGo suggested and move the nodes to the new polling engine separately.

Having personally done two of the three Orion server migration processes, I can say that the documentation for each (linked in the first post in this thread) is basically on point. Doing your homework and some basic planning knowing the specifics in your environment is important, but once you've got that, the documented instructions are the steps you need to take.

Level 12

Thanks for the feedback

I had another thought on this as well

I can't foresee any issues with this idea but wanted to run another idea past the group...we have 20 APEs...which obviously adds a lot of work to the entire process...one of the hang-ups our server team has is that they don't want to be sitting around for hours changing server names and IPs...If I ran some servers @ 2012 and some @ 2019 would there be any issue with that?  This way over the next 2-3 weeks we could slowly build out the new servers and bring them up to 2019 giving them breathing room between server re-names etc

Just a thought

Level 10

My initial reaction for you here would be yes, what you are trying to do could be done over time. There shouldn't be any issue running some APEs at 2012 and some at 2019.

I think what I'd do in your case at a very high level is to stand up a new 2019 server, install a new APE on that server using your current Orion version (which I assume is supported on 2019), do the rename/re-ip shuffle if need be (personally I might try to get away with not doing that but I get why you might have to), and get your nodes on the APE that has "new" OS and "old" Orion. Assuming that works, rinse and repeat the above 20x over however long you need to. Now you'll have "new" servers with "old" Orion that you can upgrade to the latest and greatest when everything is working and stable on the new machines.

Level 9

tlally May I ask why level of support you have?  When I open cases, my experience is rarely what I would call excellent.