Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

Upgrade

Hey all.

I've been reading an talking to support about an upgrade that we need to do, but I figured I'd ask some of the black belts on the forum.

Here's the deal.

I'm looking to upgrade from a super old versions (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) to the latest and greatest.

Also looking to upgrade move everything to new servers while keeping the existing IP addresses as well.

I've been told that I need to upgrade the DB first, which is no problem. But if I do that, then my current versions supposedly won't be able to talk to the upgraded DB.

My thought was to build a new environment and slap a backup of the current production DB on to the new database and be done with it.

Just hoping someone can give me a little insight as I'm not too familiar with SW.

Thanks!

Find more posts tagged with

Accepted answers

eric.d.bryant

JW,

Please open a ticket with SolarWinds Support. They can provide a tool called the NTA uninstall tool that will remove all the db schema and programability features of previous version of NTA embedded in the Orion database. This will help you along with the install. You do have the option to roll back to the original version before the upgrade if you have a database backup and step upgrade to NTA 4.2.0 and then eventually upgrade to Orion 2019.4. The upgrade advisor will help with this:

Success Center

All comments

sturdyerde

This is similar to what we did in our environment: we built new servers and installed the same version of Orion as the old server[s]. (We did not reuse IP addresses.) We then restored the DBs from the old SQL Server to the new instance, and then upgraded the suite. Unfortunately, this does result in some window of time with monitoring data being lost during the transition, but if you want to move to new servers while upgrading, there may not be a way around that. Either way, check with support. They were very helpful for us during this process.

jhawk75

Thanks for the reply!

yeah, that's the path I'm thinking we might have to take.

As I mentioned in my original post, I'd really just like to build a whole new environment and restore the new DB.

Then I'm pretty sure I would be able to change the IP address to the original using the configuration manager.

I guess I'm keeping it too simple.

aLTeReGo

sturdyerde's suggestion above would be the recommended approach. I would recommend

install the latest versions on the new server but cancel the Configuration Wizard when it launches
shutdown the old server
take the IP address and hostname of the old server to the new server
restore the database from old SQL server to the new SQL server
run the Configuration Wizard against the old SQL database on the new database server
Sit back and sip your coffee

jhawk75

Perfect.

So I don't necessarily need to do a laddered approach? Totally what I was hoping for.

Here's what I have from your suggestions with a couple of changes because the NTA server is running on another server and is 4.1.2. Was informed that the current data can't come over.

1: Install latest versions (NPM, NTA, ect) on new 2019 server with 30 day eval

2: Cancel the config wizard for now

3: Restore old db from SQL 2012 to new SQL 2017

4: Run the config wizard

5: Test to make sure it looks good with the previous data

6: Reclaim licenses from old and activate on new

7: Shut down the old environment

8: Change the IP and host name of the new environment using the old information

9: Run the config wizard again

10: Test and enjoy coffee

I'm just thinking that I should be able to set the new environment up and be able to see if everything looks good before actually flipping it. Least I hope.

Thanks again for everyone's input!

aLTeReGo

Changing the hostname after the configuration wizard has run is not a simple process and will require that you complete a number of additional steps. My recommendation is to not run the Configuration Wizard on the new environment until you shut down the old server. If something should go wrong though, you can certainly shut down the new server and power back on the old server to get back up and running quickly.

jhawk75

Gotcha.

I thought about that as well.

What about just changing the IP?

The host name doesn't really matter since I can always DNS that.

If you suggest holding of all together with the config wizard until the very end without testing, I can live with that.

jhawk75

Hey aLTeReGo,

Quick question as I'm finally about to roll with this thing.

When I restore the database with the old backup, is the new version of SW going to be mad that it's not the same version?

I imagine that the SQL schema is different.

Thanks!

aLTeReGo

Upgrading the Database schema is handled by the Configuration Wizard. As long as a direct upgrade path is supported from the version you're running to the version you're going to, then there should be no issue. If you're concerned, you can do a dry run on another machine using a 30 day evaluation.

jhawk75

Awesome.

Should I create a new db or just restore the current db to the new server and proceed through the warning.

I'd figure that it should be fine to proceed, but just want to make sure that our current environment is untouched.

jhawk75

Everything was looking good until i got this:

Makes sense since the backup of the old database is going to have info on that. Since the old data was on a different server and I accepted that we were going to start over, I was hoping that it would just install a new instance.

Is there a way to purge any previous information of the previous NTA installation?

Thanks!

aLTeReGo

To remove the Netflow data previously collected by an earlier installation of the NTA module, you can run a truncate command on some of the NetFlow tables.

Note: All historical Flow data will be lost by clearing these tables.

Open the Orion Database Manager and connect to your SQL server.
Expand the NetPerfMon table for your NPM server and right click the noted tables in Step 6 to select query table.
Input the relative query command for each table listed into the white space, and delete the default select.. query.
Verify that the Read-Write option is selected.
Select Refresh to execute the truncate query command.
Repeat for each of the following tables:

truncate table NetFlowSummary1
truncate table NetFlowSummary2
truncate table NetFlowSummary3
truncate table NetFlowDetail_### (where ### is relative to your table instance)
truncate table FlowCorrelation

After completing, run a shrink on the database using the Microsoft SQL Manager to clear the unused white space that was created with the truncation. See Microsoft Support documentation for these SQL server steps.

jhawk75

Hmm. There isn't a NetPerfMon table. The data is actually on a

different server that using the old flat file based storage.

On Tue, Nov 26, 2019 at 10:52 AM aLTeReGo

image.png

aLTeReGo

NetPerfMon is the default name of the database. In your case, it appears you are already using NTA a version that utilizes SQL is that correct? This may be a question better suited for jreves

jhawk75

Hi aLTeReGo,

Just or clarification, the server mentioned in the database settings for NTA, den-mon-003, isn't going to be upgraded. The thought was that it would go away since NTA was to be installed new on the new box. Also know that all data was going to be gone from NTA as well.

Am I dead in the water? How can I bring jreves in this conversation?

Thanks again for all the help!

jreves

Justin, I'll ask one of our senior engineers to connect with you to help clean this up.

In the mean time, here's an article that explains how to delete obsolete collectors from the database: Success Center This may resolve this issue for you -

jreves

jhawk75

Just wanted to give you guys an update. After running the NTA cleanup, everything went nice and smooth. Just had to get everything from the old out of there.

Now it's time to massage everything and cut over.

Thanks again for all of the assistance. Totally in your debt.

Thanks!

jhawk75

Just wanted to say thanks to everyone for the assist on my upgrade/migration.

Everything is running 2019.4 on our Win2019 servers.

Couldn't done it without your assistance.

In a nutshell, here's what I did.

Build new servers

Take a backup of the SQL database

Install 2019.4

Restore the new database with the backup

Run NTA cleaup tool

Change SQL tables to the new servers

Run configuration manager

Everything is running perfectly.

Thanks!