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.

201 Comments
MVP
MVP

Hi aLTeReGo

I am planning to migrate from Win 2012 R2 to Win 2016

I have a couple queries though:

1. 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? Is this automatically taken care ?

2. What if i change the name of the server ? I would like to reclaim the same name/fqdn for the new server?

3. And I am assuming i have to get a new SSL as I already have an alias name for the existing one.

Product Manager
Product Manager

1. 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? Is this automatically taken care ?

Deactivation/Reactivation is not necessary using this method.

2. What if i change the name of the server ? I would like to reclaim the same name/fqdn for the new server?

I would recommend against that as there's quite a bit of additional work required with really no benefit. I would recommend instead, creating a DNS record for the old server name and point it at the new server. This abstraction layer between the server name itself and the URL users enter into their browser to access the Orion web interface is generally a good idea anyway, as it allows for greater flexibility should you ever introduce Additional Web Servers into your environment later.

3. And I am assuming i have to get a new SSL as I already have an alias name for the existing one.

A new SSL certificate is not required if you're still accessing the web interface using the original servers name. This is true even if that name is a DNS alias.

MVP
MVP

Hi aLTeReGo​,

2. What if i change the name of the server ? I would like to reclaim the same name/fqdn for the new server?

I would recommend against that as there's quite a bit of additional work required with really no benefit. I would recommend instead, creating a DNS record for the old server name and point it at the new server. This abstraction layer between the server name itself and the URL users enter into their browser to access the Orion web interface is generally a good idea anyway, as it allows for greater flexibility should you ever introduce Additional Web Servers into your environment later.

Would i need to make additional changes on SolarWinds Orion or any known dependencies if we decide to change the the name of the server ?

My current setup and details are as mentioned below:

1. Am already using an alias name for this one and server name is not exposed to end users for Web. The alias name is what has been provided to end users, that's the reason i was asking about SSL cert

2. To start with I wanted to move my existing SolarWinds Orion from Win 2012 R2 to Win 2016 via HA solution which is mentioned on this post

3. Then upgrade Solarwinds modules to the latest versions

4.Then create an actual HA with a new pair on Win 2016

5. Another reason is most of the end devices are still using v2 and under allowed ip list they have provided the hostname of this device

Product Manager
Product Manager

1. Am already using an alias name for this one and server name is not exposed to end users for Web. The alias name is what has been provided to end users, that's the reason i was asking about SSL cert

Good deal! This will make any migration method you choose easier.

2. To start with I wanted to move my existing SolarWinds Orion from Win 2012 R2 to Win 2016 via HA solution which is mentioned on this post

Yes, the above method, is in my opinion, a much easier method than the alternative while also allowing you to do so with zero downtime.

3. Then upgrade Solarwinds modules to the latest versions

Sounds like a solid plan

4.Then create an actual HA with a new pair on Win 2016

Even better!

5. Another reason is most of the end devices are still using v2 and under allowed ip list they have provided the hostname of this device

As a general rule I would not recommend relying upon NetBIOS hostnames as a security method, as it's fairly trivial for anyone to spoof. It's unlikely however, that NetBIOS is really being used as this method won't work across Layer 3 boundaries. At least not unless you are also running a WINS server. In which case, you could simply create a new WINS entry for your hostname, no different than DNS.

More more likely however, is that those systems are still relying upon DNS for their name to IP address lookup. In which case, the alias method I recommended above is still the best option. You simply just need to ensure that you not only create the forward zone entry, but also a reverse zone entry as well.

Level 11

I ran into this same issue today on a 12.1 system. After a little digging I found that the LicensingMainServerName in the WebSettings table was still set to the old server. I updated that to the new server, then it let me remove the pool.

Level 7

Does this method have issues with NTA 4.2.3 on dedicated server? I am receiving the following message in the Installation phase of the HA setup.

We are unable to download file SolarWinds-Orion-NTA.msi from main server. Please check connection to main server and try again.

I do see the file in the programdata\solarwinds\installers folder on the main server.

I also moved it over to the programdata\solarwinds\installers folder on the new member server to no avail.

Product Manager
Product Manager

Yes, this method will work with that version. Please follow the steps outlined in the KB article below to resolve this error. Essentially you need to copy the file to a different directory.

Failed to download or run the Scalability Engine installer from the main server - SolarWinds Worldwi...

Level 9

I followed this procedure and migrated from 2008 to 2012.  Now I'm trying it again, to migrate from 2012 to 2016, I get an error when trying to set up the HA Pool.  "An item with the same key has already been added". 

"exceptionMessage": "An item with the same key has already been added.",

"exceptionType": "System.ArgumentException",

"stackTrace": "   at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)\r\n   at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)\r\n   at SolarWinds.Orion.HA.WebApi.DataAccess.HAPoolRepository.GetListOfOrionServers()\r\n  

I tried clearing the HA info from the database as mentioned above with

truncate table HA_FacilitiesInstances

truncate table HA_PoolMemberInterfacesInfo

truncate table HA_PoolMembers

truncate table HA_Pools

truncate table HA_ResourcesInstances

and restarting the HA service and all the Orion products, but I still get the error.

"url": "http://MyNew2012ServerName:8787/api2/ha/deploymentsummary/orionservers"

thoughts?

Level 9

Also, that doesn't seem to be clearing the tables for me if I look in SSMS....  I have 0 records in HA_Pools in the DB, but I do have records in the table PoolMemberInterfacesInfo and HA_PoolMembers showing the names and IP of the old server.  Should I just delete all entries in all those tables through SSMS?  I did it while the HA service was stopped to make sure it wasn't immediately repopulating the table.

Level 9

I had run into this as well.. even the file on my main server didn't match what the installer was looking for. (found the error when saving the diagnostics via installer.)

I followed the url the installer was trying to nab to download the version it was seeking and copied it to the programdata\solarwinds\installers folder. This allowed the installer to progress as needed and I was able to get HA up and running.

Level 9

aLTeReGo , support just closed my ticket and is going to have a pre-sales engineer reach out.  I guess it's because I mentioned I was using the Eval HA license as described in this walkthrough 😞  Maybe they will be able to help.

Level 8

I have 1 main poller, 3 APE, and a web server, all running on Server 2k12r2. Can I upgrade the main poller first and continue to run the APE on the old SolarWinds version? After the upgrade of the main poller, upgrade the APE one by one. This is due to limited resources in our VMware environment, therefore I would like to spin up a server one at a time.

Product Manager
Product Manager

Additional Polling Engines will not function properly if they are not running the same version as the main Orion Server.

Level 9

I fixed my problem myself.  There were two copies of one of the servers in the OrionServers table.  One in lowercase, one in uppercase.  I backed up the database, deleted the record in lowercase and ran the config wizard on both servers.  The error went away.  I was then able to create the pool with the 2016 server, and fail the pool over and remove it.

Level 9

Woohoo.  I've used this guide to get from 2008 to 2012, then to 2016 with a few SQL migrations too (now at 2017).  However, I'd like to keep going and get to Windows Server 2019.  When I run the installer from HA installer, It tells me Windows Server 2019 does not meet the system requirements for selected products.  I think I've upgraded all my products to a version listed as supported by 2019.

I tried downloading a new OrionNPM installer from the Solar Winds website, and work through an HA installation option, but have the same error.

Virtualization Manager v 8.3.1

User Device Tracker v 3.3.2

Network Performance Monitor v 12.4 HF 1

NetFlow Traffic Analyzer v 4.5 HF 1

Network Configuration Manager v 7.9

IP Address Manager v 4.8.1 HF 1

pastedImage_0.png

Product Manager
Product Manager

You are a hotfix or two behind. Server 2019 support was added in one of the most recent hotfixes.

Level 9

Sorry to use this thread as my personal blog, but I thought maybe the feedback would be helpful, and also since the support team doesn't appear to support this awesome easy button method.  The Feb 2019 Offline hotfix bundle installer says all my products are already up to date as far as hotfixes (I think the IPAM 4.8.1 HF 1 was the fix included in that).  If I run a fresh install rather than a HA protection install, with the exact same versions of the products on the new server, it's fine.  It seems to be something specific about trying to do the HA option and Windows Server 2019.

Level 9

lastly, wasn't sure if the weird text in the resolution details might provide any insight

pastedImage_0.png

Product Manager
Product Manager

Are you able to try the online installer?

Level 9

I tried the online installer for NPM, VMAN, and even the VMAN 8.4 RC on the future 2019 server, and they all give the same error.  I was kinda thinking the issue is something about VMAN, because if I click the "download button below to download the previous versions of the product that supports this operating system", it's usually a link to the VMAN Offline installer. (Solarwinds-Orion-VMAN-8.3-OfflineInstaller)

Level 9

I'm also thinking it might be VMAN, since the newest version, "8.3.1" isn't listed as compatible with 2019.  But it's also not listed as compatible with any OS on the app/compatiblity matrix as far as that's concerned.  Unless 8.3 means 8.3 with any service pack, but the other 8.x.x have been spelled out specifically, like 8.2.1.

pastedImage_0.png

Product Manager
Product Manager

That is simply a documentation error. It's difficult to maintain all these matrices as new versions are released. I'll see that this one gets updated. Thanks for pointing this out!

Product Manager
Product Manager

Can you post the installer log file so we can try and figure out why you're receiving this error?

Level 9

***Log file removed since it dirtied the thread and wasn't very helpful***

Level 9

Also, If I run the catalog JSON file in the same directory through a beautifier,  their are oddities in the supported OS values for Orion 2018.4 HF1 platform

          "OsVersions": [

            "Windows81",

            "Windows10",

            "WindowsServer2016",

            "Undetected"

    

  {

      "Id": "ORIONPLATFORM",

      "Type": "Component",

      "Name": "Orion Platform",

      "Description": null,

      "IsAutomaticUpdateAvailable": true,

      "ReleaseDate": "2018-12-20T00:00:00Z",

      "LicenseName": null,

      "LicenseVersion": null,

      "ProductFamily": null,

      "IsVirtual": true,

      "Version": "2018.4.5220.9599",

      "DisplayVersion": "2018.4",

      "UpgradeFrom": "2018.4.5220.9523-2018.4.5220.9599",

      "Installers": [

        {

          "Conditions": null,

          "Name": null,

          "Cpu": "x64",

          "Repository": "https://support.solarwinds.com/Success_Center/Orion_Platform/Orion_Documentation/Orion_Platform_2018...",

          "Size": 0,

          "Checksum": null,

          "UpgradeCode": null,

          "ProductCode": null,

          "Version": null,

          "InstallType": "ReleaseNotes",

          "CommandLine": null,

          "Uninstall": null,

          "OsVersions": [

            "Windows81",

            "Windows10",

            "WindowsServer2016",

            "Undetected"

          ],

          "RequiredInstallationSpaceMbytes": 0,

          "RequiredMemoryInMbytes": 0,

          "InstallationLocation": "InstallationFolder"

        },

        {

          "Conditions": null,

          "Name": null,

          "Cpu": "Any",

          "Repository": null,

          "Size": 0,

          "Checksum": null,

          "UpgradeCode": null,

          "ProductCode": null,

          "Version": null,

          "InstallType": "ProductInfo",

          "CommandLine": null,

          "Uninstall": null,

          "OsVersions": [],

          "RequiredInstallationSpaceMbytes": 0,

          "RequiredMemoryInMbytes": 0,

          "InstallationLocation": "InstallationFolder"

        }

      ],

Level 7

Was wondering if this would work to upgrade a standalone solarwinds server with both Solarwinds and SQL installed, and move to another standalone server with both Solarwinds and SQL installed.

We are not very big, currently our solarwinds works fine on one server.

Currently have Server 2012R2 with SQL 2012, need to move to Server 2016 with SQL 2017.

I tried in a test environment moving solarwinds to the new server, with SQL still running on the old server.

But when I try to fail over, it stops working.

My plan was to move over solarwinds using this method, then move the database over.

Product Manager
Product Manager

The Orion server migration portion yes, but you would then need to migrate the SQL database server separately which would require some degree of downtime to re-run the Configuration Wizard.

Level 9

Any more thoughts on my issue?

It seems like if I try to do a fresh install on the 2019 box, it pulls down a good copy of the json catalog, but if I try to do a migrate from 2016 to 2019, it pulls the catalog.json from the 2016 box which doesn't indicate 2019 compatibility in the JSON file.  I tried replacing the c:\programdata\solarwinds\installers\SolarWinds.Administration.ProductCatalog.Model.ProductCatalogModel_default.json on the 2016 server with the good one from a fresh install on the 2019 box,  and replacing the word undetected with the word WindowsServer2019 in the SolarWinds.Administration.ProductCatalog.Model.ProductCatalogModel_installed.json file in there.  But then the HA program gave me this error, so I put the originals back.

pastedImage_0.png

If I put the good and bad JSON files next to each other in a beautifier, it seems clear that that if the SupportedOS values were fixed, it would go through.

pastedImage_1.png

The good catalog version is 235362, but the HA Migration assistant always seems to reference catalog version 228944 for some reason

pastedImage_2.png

Product Manager
Product Manager

This method of migration will not allow you to bypass the OS limitations of the version you're running. In your case, Orion Platform 2015.1 did not support Windows Server 2019, so the installer is trying to protect you from configuring HA on a machine where it won't work. I would recommend upgrading to Orion Platform 2018.2 before migrating to Server 2019.

Level 9

@ Bosco,

It appears that you installed the Additional Polling Engine software because the error says that it couldn't connect to the main polling engine?   Can you please verify that for me?

Because you should have installed like NPM on the 2019 server and got it up and running and then do the HA.

Level 9

In making that particular screenshot, I might have chosen the wrong option.  I went through the wizard so many times, I started hurrying through.  Anyhow, I finally got it migrated.  After I manually tried editing the JSON file on the source box, Solar Winds got kinda wonky even after I put the original JSON file back.  So I ran a config wizard on the original box to get it functioning again.  I then went through the HA pair migration wizard again, and it no longer errored that Windows 2019 was undetected.  So I went through the process of making the pair, failing over, and removing.  My update/migrate saga is finally done!

I still think it hinged around that JSON file, since I never could find a copy of Windows Undetected on the MS volume licensing site 😉

pastedImage_0.png

Level 9

Well, I am glad that putting the original JSON file back worked and you were able to get migrated ok.  Thanks for sharing your experiences.

Level 8

I have finally pulled the trigger and cutover to the new 2016 server.

I did have some issues where it was looking for the old server, but I followed what someone else mentioned about updating LicensingMainServerName in the WebSettings table and that resolved the issue.

I still had issues with licensing, I raised a support case and the licenses were reset and then I activated them on the new server.

The one last lingering thing I have at the moment is if I go to High Availability Deployment Summary I can still see the old server there.

I no longer have a pool (as per the instructions it was removed) What do i need to do to get this old server out of the HA Deployment Summary page?

Product Manager
Product Manager

Does it still show up under [Settings > All Settings > Polling Engines]?  If so, there should be a delete/remove button next to that engine.  If there is no option to delete/remove the engine, open Database Manager on the Orion server and run the following query.

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

Level 8

Hi aLTeReGo​ the old server does not show up under the Polling engines, we have run the truncate command against the DB and it looks like it has worked... somewhat....

The old server is still lingering around under Settings > All Settings > High Availability Deployment Summary

Its grayed out and when you click on it, in the information pane on the right hand side it just has Server type as Main Poller.

EDIT - I just noticed in the database under the OrionServers table there old Server is still in there? If i remove it from that table, should that remove it from the Web Display also?

Product Manager
Product Manager

This entry is coming from the Orion.Servers table. To remove it, open the Database Manager, right click on the 'OrionServers' table, and select 'Query Table'. From the query window, click 'Enable table editing' and then right click on the row related to the HA member which no longer exists. It is STRONGLY recommended that you take a backup of your database before doing this, as this action cannot be undone. If you were to accidentally delete the wrong row, your only recourse would be to recreate the row with the previous values or restore from your backup.

pastedImage_0.png

Level 9

Hi, I am about to move forward with updating my 2017.3 environment with NPM, NCM, NTA, SAM and WPM to new 2016 servers, so I can upgrade to Latest 2018 versions.

When I move my Main Server to the Windows 2016 server, will it still work with the Windows 2012 NTA Fastbit Server?  Or will I be required to reinstall the NTA application on the 2016 server?   Any issues with netflow records after updating the CNAME so New Windows 2016 server has old server IP?

Product Manager
Product Manager

lsalinas  wrote:

Hi, I am about to move forward with updating my 2017.3 environment with NPM, NCM, NTA, SAM and WPM to new 2016 servers, so I can upgrade to Latest 2018 versions.

When I move my Main Server to the Windows 2016 server, will it still work with the Windows 2012 NTA Fastbit Server?  Or will I be required to reinstall the NTA application on the 2016 server?   Any issues with netflow records after updating the CNAME so New Windows 2016 server has old server IP?

Not sure if you've seen the documentation on this, (NTA 4.4 and later installation FAQs - SolarWinds Worldwide, LLC. Help and Support )  but in the latest versions of NTA, there has been a change of database technology used. There is no migration path from fastbit to the new SQL database backend. I would recommend making your life easier by not trying to jump through hoops to migrate your fastbit database unnecessarily when you will need to set up a new DB to house your data for the lasted bits anyway.

Level 9

Yes, I have seen that documentation, which is why I ask.  My ideal state would be to migrate main Orion server to Windows 2016, Leave NTA server and Fastbit DB on Win2012.  Then after we can verify everything is working, do an upgrade to Orion 2018.x at a later date.   Just wanted to confirm that leaving NTA server and FB DB on Win2012 was ok, and supported.

Hope that makes sense.

Product Manager
Product Manager

lsalinas  wrote:

Yes, I have seen that documentation, which is why I ask.  My ideal state would be to migrate main Orion server to Windows 2016, Leave NTA server and Fastbit DB on Win2012.  Then after we can verify everything is working, do an upgrade to Orion 2018.x at a later date.   Just wanted to confirm that leaving NTA server and FB DB on Win2012 was ok, and supported.

Hope that makes sense.

You can certainly leave NTA and the fastbit behind on the 2012 server. The only question is - are you expecting that NTA would be on both the old server and the new or just existing on the old server?

Level 9

If it is Supported leaving Fastbit on the old 2012 server.  I would expect it to remain only on the old server, until I upgraded to Orion 2018.x, when it would move to the SQL 2016.1 DB server.

Product Manager
Product Manager

lsalinas  wrote:

If it is Supported leaving Fastbit on the old 2012 server.  I would expect it to remain only on the old server, until I upgraded to Orion 2018.x, when it would move to the SQL 2016.1 DB server.

It is supported, by virtue of the fact that you've purchased a perpetual license so you can choose to deploy it on a separate server or combined, that's all up to you.

Product Manager
Product Manager

When you are ready to move it, if you need a temp key to run in parallel while you populate the flow data for your retention period, you can contact me directly.  The FREE Flow Tool Bundle | SolarWinds includes a flow replicator that would allow to replicate your existing stream of flow data to a new server, if that helps. It sounds like you are planning to place both the Orion db and the NTA Flow db on the same SQL server, correct?

@jreves

Level 14

I've got a multi engine, multi module Orion with a bunch off AWSs behind a load balancer. The OSs are a mix of WS2012R2 & WS2016 and I want to end up with the latest Orion on the latest.OS. Starting from the MPE with NPM12.3 on WS2012R2 i've spent some time trying to work a path & I think I finally have it now.

  1. Shutdown all AWSs & APEs
  2. Backup SQL
  3. build new WS2016 (new IP)
  4. Install as HA,
  5. migrate the original WS2012R2 MPE to new WS2016 HA server using HA functionality
  6. shut down & remove from pool the original WS2012R2 MPE (Original IP)
  7. stand up a new SQL for NTA
  8. upgrade Orion on new WS2016
  9. build new WS2019 (Original IP)
  10. Install as HA,
  11. migrate to new WS2019 HA server,
  12. shut down & remove from pool the WS2016
  13. check all & be prepared to do a ConfWiz or fiddle with tables as necessary
  14. standup a bunch of new WS2019 servers and
  15. deploy & configure APEs & AWSs using the new central console functions
  16. and test everything
Level 9

Thanks.  I will look at that when I get to production migration with our important flow data.

BUT, I can't get the HA installer to work.  It says it can not find the NTA.MSI file on the main server, and the success center workaround didn't work for me.  Any advice, updated workarounds?

Success Center

Product Manager
Product Manager

Can you confirm the NTA MSI is located under 'c:\ProgramData\Solarwinds\installers' directory.

Level 9

Yes, the SolarWinds-Orion-NTA is located in the C:\ProgramData\SolarWinds\Installers directory.

Product Manager
Product Manager

lsalinas  wrote:

Thanks.  I will look at that when I get to production migration with our important flow data.

BUT, I can't get the HA installer to work.  It says it can not find the NTA.MSI file on the main server, and the success center workaround didn't work for me.  Any advice, updated workarounds?

Success Center

Usually that means that there's not an expected file on the main polling engine. Can you create a support ticket so we can then get access to your diags?

Level 9

Yep. Will open a ticket.

Thanks

Level 7

This worked great for me, but it took a couple of hours to figure out that the HA service doesn't work (status was gray) unless the default recipients and default sender email settings are configured.