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
Level 9

Hi, if I use this method without plan to keep/purchase High Availability, will the "High Availability license expired" show up in the banner and license manager? Or will it be gone once the HA disabled per last step? Thank you

Product Manager
Product Manager

rarko  wrote:

Hi, if I use this method without plan to keep/purchase High Availability, will the "High Availability license expired" show up in the banner and license manager? Or will it be gone once the HA disabled per last step? Thank you

The evaluation banner will disappear once HA is expired. Also note that the evaluation banner is only visible to Orion Admins, not regular Orion users.

Level 14

davidstojak what a unexpected requirement for HA

Product Manager
Product Manager

robertcbrowning  wrote:

davidstojak  what a unexpected requirement for HA

It's not at all a requirement and I cannot explain how or why that worked. I was not able to reproduce that behavior in my own environment.

Level 14

Good to hear.. Thanks.

Level 8

Quick question.  Dont i have to actually load SAM and NPM prior to this procedure?

Product Manager
Product Manager

mnutter  wrote:

Quick question.  Dont i have to actually load SAM and NPM prior to this procedure?

This procedure can be used with any Orion Platform module. If you don't own SAM or NPM, there's no need to install either of them. You can for instance, follow this same process if you only own IPAM, or NCM.

If your question is do you need to install your product modules on the new server ahead of time, the answer is 'no'. The installation of Orion High Availability on the new server will make an exact replica of products and versions installed on your existing server.

Level 8

Yes we own both SAM/NPM/Additional polling machines 2.  

That rocks!!!! thank you part two was exactly what I needed. 

Level 8

So I am trying this because I want to migrate from 2012 R2 servers to 2016 BUT my NTA version is 4.2.3. The database is currently being saved to a drive on a separate server from the Orion server. So when I run the Config wizard on the new server it does not give me the option to save the NTA Database to a separate server. It only lets me save to a drive on the new server. Meaning, I can't enter a hostname or IP of the database server. However, when I run the config wizard on the original server it lets me enter a hostname or IP for the NTA database location. Why on the new server do I not have that same option???   I am aware that when I upgrade my orion products I will lose my NTA database because the newer versions of NTA store the database with in SQL.

Product Manager
Product Manager

David,

The steps for migrating the older NTA flow storage database can be found in this KB: Migrate the NTA Flow Storage database to a new remote server

Have a look through that, and let me know if you have any questions -

jreves

Level 8

Where can I determine if I'm running Orion Platform 2017.1 or earlier.  

I found in settings all > Orion Platform Details >  ??

But which line for sure?

I believe I have

ACCOUNTLIMITATIONBUILDER.EXE2017.03

I see the 2017.03 reference listed many times on the exes.

Am I even close here in the logic or is their a definitive line that I should be looking for?

Thanks,

M.

Level 8

Correction above 2017.3

Level 8
SOLARWINDS.ORION.HIGHAVAILABILITY.API.DLL2017.3.1.3303
SOLARWINDS.ORION.HIGHAVAILABILITY.AUDITING.DLL2017.3.1.3303
SOLARWINDS.ORION.HIGHAVAILABILITY.COMMON.DLL2017.3.1.3303
SOLARWINDS.ORION.HIGHAVAILABILITY.DLL2017.3.1.3303
SOLARWINDS.ORION.HIGHAVAILABILITY.STRINGS.DLL2017.3.1.3303
Product Manager
Product Manager

mnutter  wrote:

Where can I determine if I'm running Orion Platform 2017.1 or earlier.  

I found in settings all > Orion Platform Details >  ??

But which line for sure?

I believe I have

ACCOUNTLIMITATIONBUILDER.EXE2017.03

I see the 2017.03 reference listed many times on the exes.

Am I even close here in the logic or is their a definitive line that I should be looking for?

Thanks,

M.

The version Orion Platform installed appears listed in the footer of the Orion web interface.

pastedImage_0.png

Level 8

pastedImage_0.pngso

Level 8

I believe that means I'm good for the HA migration?

Product Manager
Product Manager

mnutter  wrote:

I believe that means I'm good for the HA migration?

It would appear so!

Level 8

New issue, once the main server has been contacted during the install I get the following error:

pastedImage_0.png

Product Manager
Product Manager

I believe this issue, and its resolution, are outlined in the following KB article.

https://support.solarwinds.com/SuccessCenter/s/article/NPM-12-0-Installer-failed-on-Specified-MSI-in...

Level 8

So I figured out why this error is popping up. When I looked at the log file I realized the installer is looking for a specific version of the SolarWindsActiveDiag.msi file. Specifically it is trying to match the HASH for that version and if they don't match you will get this error. My installer was looking for version 7.4 or something but the version that was on my original server was 8.2 so the HASH didn't match and I got this error. All I did to fix this was download the version of the SolarWindsActiveDiag.msi file that the installer is looking for and put it in this location, C:\ProgramData\Solarwinds\Installers\ActiveDiagnostics on the original server and my installer ran without issues on my new server. I wish I would have taken a screenshot of the log file but I didn't. The logs are located here.  %ProgramData%\Solarwinds\Logs\Orion\ServiceDirectory

Level 9

So I tried it today but I cannot failover to the new server, it's keep on failing back to the old one. I believe I followed the guide to the letter, but maybe I overlooked something like HA requirement (SolarWinds High Availability requirements ). Do we need to follow all that? My goal is strictly to migrate the engines to 2016 servers (from currently 2012), retain the IPs of the old boxes for the new ones, then retired the old ones. Any pre-requisites that maybe a common knowledge but not written in the article? I have zero knowledge of HA TBH, so any little advice will helps. Thank you.

Product Manager
Product Manager

Have you reviewed the Orion Events? There should be a message there which explains the reason for the pool failing back.

Level 8

Thanks for the guide, I was wondering if you could help with the issue i'm experiencing when I try to remove the pool - it says the pool cannot be deleted because the other node needs to be the active one. It also mentions an issue with the Licensing because the main server is 'completely down'

the creation of the pool and the fail-over seemed to work fine, it's just the final stage of removing the old node where I'm stuck. The new node is now the active one and the old node is in standby.

I'm sorry I don't have any screenshots because I was keen to get it back up and working before I started troubleshooting the issue.

Level 8

Its a great guide, Thank you for putting the procedure clear

Product Manager
Product Manager

george.subnet  wrote:

Thanks for the guide, I was wondering if you could help with the issue i'm experiencing when I try to remove the pool - it says the pool cannot be deleted because the other node needs to be the active one. It also mentions an issue with the Licensing because the main server is 'completely down'

the creation of the pool and the fail-over seemed to work fine, it's just the final stage of removing the old node where I'm stuck. The new node is now the active one and the old node is in standby.

I'm sorry I don't have any screenshots because I was keen to get it back up and working before I started troubleshooting the issue.

Please try following these steps. As always, ensure you have a backup of your database and a snapshot of your VMs (if possible) before proceeding.

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

Just curious if anyone has seen after running the Configuration Wizard.  We have been having issues with our existing primary poller where it shows the polling engine as down.   After the first configuration wizard failure, I went to the primary poller and restarted the services and am attempting to re-run the COnfiguration wizard now.

pastedImage_0.png

Level 9

I went through the logs, and it appears that the NTA is the reason. NTA failed to start, it looks like that it cannot get the correct configuration. I have the NetFlow Storage on separate server, but from the logs it seems that the storage server wasn't recognized at all.

Product Manager
Product Manager

Rahno, do you have a support ticket open on that issue already?  Are you on a later (4.4 or later) version of NTA, or still on 4.2.3?

jreves

Great step by step approach but how would one go about this if I have my Orion and database server separated out on 2 different machines?

I already have prepared 2 new 2016 servers, I've read that I should move over the database first and then focus on the application side.

Product Manager
Product Manager

greenpaddyirishman  wrote:

Great step by step approach but how would one go about this if I have my Orion and database server separated out on 2 different machines?

I already have prepared 2 new 2016 servers, I've read that I should move over the database first and then focus on the application side.

The instructions above assume your Orion application server is separate from your database server. Migrating your Orion database to another SQL server is relatively simple and straightforward. Instructions on doing so can be found at the links below.

https://documentation.solarwinds.com/en/Success_Center/orionplatform/Content/Migrate_the_SolarWinds_...

https://support.solarwinds.com/SuccessCenter/s/article/Upgrade-and-migrate-the-database-to-a-new-ser...

Good to know - so the database can be upgraded/migrated first and all the modules will continue to run until they are ready to be upgraded using your step by step guide correct?

Product Manager
Product Manager

greenpaddyirishman  wrote:

Good to know - so the database can be upgraded/migrated first and all the modules will continue to run until they are ready to be upgraded using your step by step guide correct?

Correct. The database migration can occur before or after following the steps outlined here in this post. The choice is really up to you.

Level 9

Hi, no, i don't have ticket open unfortunately, i'm rolling back the migration, and everything is back to before the attempt. I saved the logs folder somewhere else though. As for the NTA, we are still on 4.2.3. I'm planning to do the NTA upgrade after the OS migration.

Also one question about this article, for this migration using HA to work, what is the firewall requirement? I'm planning to re-use my old IP, so I don't need to have a new firewall modification to be added for the servers. However for the migration as described by this article, I wonder if I need to get the firewall done for the new 'temporary' IPs for this to work correctly?

Level 9

Hi fletchmasta, so how did it goes for you? I have the same question, and it might be the reason the NTA keep on failing on the new server.

Level 7

This looks like a great idea.  I have different SolarWinds setup however.  My application server has 2 interfaces.  One interface where servers wmi and snmp communicate and one interface where network gear (routers and switches) communicate via SNMP.  Will the HA setup support 2 separate networks on each HA server?

Product Manager
Product Manager

yes, Orion High availability can work with multiple interfaces, but only one will be used for for the VIP or virtual hostname. Note that the VIP or virtual hostname is used only for accessing Orion (usually the web interface), not for polling devices.

Level 9

So I finally completed my migration last week, and today the upgrade to 2019.2. It's been a long journey but I'm happy now that it's over. I did it the "old fashion" though as I didn't have time to tinker further. I'm pretty certain it's working if I have no NTA 4.2.3, and will probably work if i spend more time tinkering with it, which unfortunately is luxury that I cannot afford at the moment. In fact I was successfully running this method on my test servers, but not in my productions. I will most likely attempt this method using HA again for my next migration.

Level 8

I get:

Could not get installer metadata from administration service on main polling engine. Please contact SolarWinds support.

Is there a log file that can give me more info about what’s really happening behind the error?

Level 11

Hello, Ty.

Try the C:\ProgramData\SolarWinds\Logs\Administration\AdministrationService.log. I searched for your error message in the SolarWinds Success Center and found this KB: Cannot receive data from SolarWinds Administration Service

Level 8

Thank you for the suggestion. I found what I'm looking for in C:\ProgramData\SolarWinds\Logs\Installer\2019-08-19_11-11-13\AdministrationService.Client.log

It looks like it got a response from the main poller engine, but couldn't get the installer metadata for some unknown reason. I tried restarting the administration service on the main poller, but that didn't help. I also found an article stating this could be caused by extra bindings on the web page, but I didn't have any extra bindings.

2019-08-20 10:03:26,896 [27] INFO  (null) SolarWinds.Administration.Installer.InstallerFacade - Solarwinds installer is started on Scalability Engine on fresh installation.

2019-08-20 10:03:26,897 [27] INFO  (null) SolarWinds.Administration.Installer.InstallerFacade - Chosen server role is: AdditionalPoller isHa: False

2019-08-20 10:03:26,897 [27] DEBUG (null) SolarWinds.Administration.SystemInfoCollector.MainPollerHostNameProvider - Getting MainPollerHostName from MainPollerHostNameProvider class: <main poller IP>

2019-08-20 10:03:26,897 [27] DEBUG (null) SolarWinds.Administration.SystemInfoCollector.MainPollerHostNameProvider - Getting MainPollerHostName from MainPollerHostNameProvider class: <main poller IP>

2019-08-20 10:03:26,943 [27] DEBUG (null) SolarWinds.Administration.Utils.RegistryReader - Could not find registry key LocalMachine\Software\SolarWinds\Orion\Core\Version

2019-08-20 10:03:26,943 [27] DEBUG (null) SolarWinds.Administration.Utils.RegistryReader - Could not find registry key LocalMachine\Software\SolarWinds\Orion\Core\InstallPath

2019-08-20 10:03:26,943 [27] DEBUG (null) SolarWinds.Administration.Utils.RegistryReader - Could not find registry key LocalMachine\Software\SolarWinds\Orion\Core\Configuration

2019-08-20 10:03:26,943 [27] DEBUG (null) SolarWinds.Administration.Utils.RegistryReader - Could not find registry key LocalMachine\Software\SolarWinds\Orion\Core\EvalInstallType

2019-08-20 10:03:26,943 [27] DEBUG (null) SolarWinds.Administration.Utils.RegistryReader - Could not find registry key LocalMachine\Software\SolarWinds\Orion\Core\InstallPath

2019-08-20 10:03:26,943 [27] DEBUG (null) SolarWinds.Administration.Utils.RegistryReader - Could not find registry key LocalMachine\Software\SolarWinds\Orion\Core\InstallPath

2019-08-20 10:03:26,944 [27] WARN  (null) SolarWinds.Orion.Core.Common.RegistrySettings - Failure opening registry key at HKLM\SOFTWARE\SolarWinds\Orion\Core\Configuration.

2019-08-20 10:03:26,944 [27] WARN  (null) SolarWinds.Orion.Core.Common.RegistrySettings - Failure opening registry key at HKLM\SOFTWARE\SolarWinds\Orion\Core\Configuration.

2019-08-20 10:03:26,944 [27] WARN  (null) SolarWinds.Orion.Core.Common.RegistrySettings - Failure opening registry key at HKLM\SOFTWARE\SolarWinds\Orion\Core\Configuration.

2019-08-20 10:03:26,944 [27] WARN  (null) SolarWinds.Orion.Core.Common.RegistrySettings - Failure opening registry key at HKLM\SOFTWARE\SolarWinds\Orion\Core\Configuration.

2019-08-20 10:03:26,944 [27] INFO  (null) SolarWinds.OrionImprovement.Client.OipClient - OIP Opt-In from User: False

2019-08-20 10:03:26,944 [27] INFO  (null) SolarWinds.OrionImprovement.Client.OipClient - Dropping all buffered OIP events.

2019-08-20 10:03:26,945 [27] INFO  (null) SolarWinds.Administration.Installer.InstallerFacade - trying to detect locale on main poller

2019-08-20 10:03:26,945 [27] DEBUG (null) SolarWinds.Administration.SystemInfoCollector.MainPollerHostNameProvider - Getting MainPollerHostName from MainPollerHostNameProvider class: <main poller IP>

2019-08-20 10:03:26,977 [27] INFO  (null) SolarWinds.Administration.Installer.InstallerFacade - detected locale on main poller: en-US

2019-08-20 10:03:26,978 [27] DEBUG (null) SolarWinds.Administration.SystemInfoCollector.MainPollerHostNameProvider - Getting MainPollerHostName from MainPollerHostNameProvider class: <main poller IP>

2019-08-20 10:03:27,027 [27] DEBUG (null) SolarWinds.Administration.SystemInfoCollector.MainPollerHostNameProvider - Getting MainPollerHostName from MainPollerHostNameProvider class: <main poller IP>

2019-08-20 10:03:27,774 [27] ERROR (null) SolarWinds.Administration.DataProviders.CachingProductCatalogProvider - Product catalog download failed. SolarWinds.Administration.Contract.Exceptions.CannotGetInstallerMetadataException: Could not get installer metadata from administration service on main polling engine. Please contact SolarWinds support.

   at SolarWinds.Administration.DataProviders.ScalabilityEngineProductCatalogProvider.GetProductCatalogModel(ProductCatalogVersion metadata)

   at SolarWinds.Administration.DataProviders.CachingProductCatalogProvider.GetModelForMandatoryVersionMetadata(ProductCatalogVersion remoteVersion)

   at SolarWinds.Administration.DataProviders.CachingProductCatalogProvider.DownloadProductCatalogFromSource()

2019-08-20 10:03:27,775 [27] ERROR (null) SolarWinds.Administration.Installer.ErrorHandler.HttpResponseAdapter - Unexpected error occured.

SolarWinds.Administration.Contract.Exceptions.CannotGetInstallerMetadataException: Could not get installer metadata from administration service on main polling engine. Please contact SolarWinds support.

   at SolarWinds.Administration.DataProviders.ScalabilityEngineProductCatalogProvider.GetProductCatalogModel(ProductCatalogVersion metadata)

   at SolarWinds.Administration.DataProviders.CachingProductCatalogProvider.GetModelForMandatoryVersionMetadata(ProductCatalogVersion remoteVersion)

   at SolarWinds.Administration.DataProviders.CachingProductCatalogProvider.DownloadProductCatalogFromSource()

   at SolarWinds.Administration.DataProviders.CachingProductCatalogProvider.RetrieveProductCatalog()

   at SolarWinds.Administration.DataProviders.CachingProductCatalogProvider.GetProductCatalogModel()

   at SolarWinds.Administration.DataProviders.CustomPackagesProvider.GetCustomPackages(IProductCatalogProvider catalogProvider, ICurrentSetupInfo currentSetupInfo, ICustomPackagesVersionsProvider customPackagesVersionsProvider, IServerRoleProvider serverRoleProvider)

   at SolarWinds.Administration.DataProviders.CustomPackagesProvider.get_Packages()

   at SolarWinds.Administration.DataProviders.CustomPackagesProvider.get_Products()

   at SolarWinds.Administration.Installer.InstallerFacade.ConfigureScalabilityEngineProducts()

   at SolarWinds.Administration.Installer.InstallerFacade.ConfigureScalabilityEngineInstallation()

   at SolarWinds.Administration.Installer.WebApi.InstallEngineController.<ConfigureScalabilityEngineInstallation>b__15_0()

   at SolarWinds.Administration.Installer.ErrorHandler.HttpResponseAdapter.ExecuteFunction(Func`1 function, HttpRequestMessage originalRequest)

Level 9

Your problem is caused by something different, fortunately it should be easy to solve.

On the main server locate the installer exe file and run it. When the page with list of product appear - you can close it. Then you should be able to proceed with update.

Technical note - that information (missing installer metadata) is related to the registry entry that stores location of the installer that was used to upgrade main server. It should be HKLM/Software/Wow32Node/Solarwinds/Orion/Installer/Path (or something similar, I am typing from my head).

Why it is missing - it's a mystery for now, that I hope we will solve soon!

Level 9

Great post.

We're running an older version and I was wondering if it's possible for us to run with this procedure.

Orion Platform 2016.1.5300, NPM 12.0, IVIM 2.1.2, NetPath 1.0, QoE 2.1.0, SAM 6.2.0, NTA 4.1.2

Level 8

Is there a post anywhere on how to do product updates once you have HA running?

We are a version behind on our modules and I need to start planning the update and just want to know whats required once you have a HA Device pool.

Product Manager
Product Manager

Product updates with HA are no different than without. You simply need to disable HA prior to the upgrade and re-enable it again once the upgrade is complete. Upgrading the HA backups is no different than upgrading any other scalability engine, such as an Additional Polling Engine or Additional Web Server.

Product Manager
Product Manager

jhawk75  wrote:

Great post.

We're running an older version and I was wondering if it's possible for us to run with this procedure.

Orion Platform 2016.1.5300, NPM 12.0, IVIM 2.1.2, NetPath 1.0, QoE 2.1.0, SAM 6.2.0, NTA 4.1.2

12.0.1 is the minimum version required to use this method, so you will need to upgrade one last time the conventional way before you can take advantage of HA to perform a zero-downtime migration.

Level 8

I'm just now getting back to this. Thank you everyone for the suggestions.

In the C:\ProgramData\SolarWinds\Logs\Administration\AdministrationService.log on the primary poller, I see the message:

2019-08-27 12:52:38,266 [3] ERROR (null) SolarWinds.Administration.DataProviders.InstallerMetadataProviderForSwa - Exception when getting installer metadata.

System.IO.FileNotFoundException: Could not find file 'C:\ProgramData\SolarWinds\Installers\SolarWinds.Orion.Installer-2.0.0.1463.exe'.

Which is what kacperm is referencing. However, after running the installer I can see that HKLM/Software/Wow32Node/Solarwinds/Orion/Installer/Path in the registry still shows C:\ProgramData\SolarWinds\Installers\SolarWinds.Orion.Installer-2.0.0.1463.exe, which is a file I don't have. I tried updating the registry to point to the newer install files I do have, but they're not compatible with my version of Orion (2018.2 HF6).

And that brings me to my request for someone on the Solarwinds team: Please fix the customer portal download link for the HA installer version "2018.2 - v2.0 [66 MB] 18 SEP 2018" so that it downloads the named version, rather than the latest version!

Thank you.

Product Manager
Product Manager

Note that you can always download the version of the Scalability Engines installer that came with your version of Orion from within the product itself. It can be found under [Settings > All Settings > Polling Engines]

pastedImage_0.png

This installer can be used for Additional Polling Engines, Additional Web Servers, or High Availability Backups.

Level 8

Negative, Ghost Rider. That takes you wherever HKLM/Software/Wow32Node/Solarwinds/Orion/Installer/Path is pointing. In my case, and ACDII's (see bottom of first page of comments) that installer it's looking for didn't exist. At your suggestion, I went into the C:\ProgramData\SolarWinds\Installers\ folder and found 'SolarWinds-Orion-Installer.exe'. That ran on my new HA server, seemed to be the correct version, but unfortunately something along the way is apparently corrupt:

Microsoft.Deployment.WindowsInstaller.InstallerException: The configuration data for this product is corrupt. Contact your support personnel.

   at Microsoft.Deployment.WindowsInstaller.Installer.OpenProduct(String productCode)

   at OrionInstallerLib.MsiDatabaseInfo.FromInstalledProduct(String upgradeCode)

   at OrionInstallerLib.InstallerInfoProvider.MsiConditionCreator(String installerFileName, XElement conditionElement)

   at OrionInstallerLib.InstallerInfoProvider.CreateConditions(String installerFileName, XElement conditionsElement)

   at OrionInstallerLib.InstallerInfoProvider.CreateInstallerInfo(XElement installer)

   at OrionInstallerLib.InstallerInfoProvider.<Load>b__11_0(XElement x)

   at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()

   at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)

   at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)

   at OrionInstallerLib.InstallerInfoProvider.Load(XElement root)

   at OrionInstallerLib.InstallChain.LoadFromXml(XElement root)

   at OrionInstaller.Program.CreateInstallChain(String[] args, VariablesManager variablesManager, InstallerSettings settings, XDocument doc)

   at OrionInstaller.Program.CreateWizard(String[] args)

So I'd REALLY like to get a clean copy direct from Solarwinds. Yes, I do have a support case open, but they haven't been nearly as helpful as this thread. Thanks again for everyone's help!

Level 8

I downloaded the version of NPM full offline installer that's compatible with my version of Orion (12.3.0 [2.93 GB] 20 AUG 2018), and it worked! My new HA poller is now showing up in my High Availability Deployment Summary with a green dot and labeled 'standby'.

Level 10

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.