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

Orion Platform 2019.2 Hotfix 2 - Now Available

Login to your Customer Portal to download

SolarWinds Orion Platform 2019.2 Hotfix 2 addresses the following issues:

  • Database maintenance issues due to rotating RabbitMQ logs were resolved.
  • Topology IP addresses are recognized correctly.
  • Network Discovery issues in Korean Locale were resolved.
  • Custom chart issues caused by handling simple SQL data sources were resolved.
  • When upgrading NPM, the Network Atlas is also upgraded.
  • Cortex no longer creates a database index on a non-existing filegroup.

Full Release Notes are available here > Success Center


Tags (1)
15 Replies
Level 12

I'm assuming this supersedes HF1? I'm on 2019.2 no hot fix

0 Kudos

Correct. Hotfixes are cumulative. Meaning that all you need to do is install HF2 and you also receive all fixes from HF1.

I installed this Hotfix a week ago (8/16/2019) without serious issues.  I found a few places where the user experience could be improved, but after a few missteps and some concern on my side about red items alerting me to things that I didn't need to be alerted on, it ultimately installed without issue.

Some ideas for future hotfixes' improvements might include:

  • The alert about first backing up your database, and having to accept it.  One would think a computer / server would have some internal record of a backup being made within the last X minutes.  The hotfix installer should be able to recognize it and not present that alert/alarm if the database has been recently backed up.
  • There should never be any alerts or errors displayed if the recommendation is to ignore them.  Let's hope Solarwinds can always recognize the need to avoid alert fatigue.  If it can be ignored, it shouldn't show up at all.
  • The hot fix install on my main instance hung with this error.


     I took a chance and simply restarted the server and that fixed the issue.  A better experience would be either not requiring the restart, or providing information at the hanging instance that says "This error is expected.  Please restart the server, and the installation will continue normally", or letting the hot fix restart the server on its own.

  • The other six APE's seemed hung until the main instance successfully completed its hot fix installation.  Somehow I envision a hotfix process that better explains what's about to happen, what not to be concerned about.
  • During the time when the other APE's seemed hung, I shared my concerns with SW via a ticket (Case # 00371397).  One part of the response included this recommendation:

     "If the APEs are not updating when you do it on the Orion deployment. Try running your APE installer on the APE, but you have to do it one at a time. Also, make sure the main poller is done updating with HotFix before doing it on any of the APEs. Please note that installer of the main poller is different from installer of APE or AWS or HA standby servers.   I suggest do it on off hours as each of them will run Config Wizard which will also restarted the Orion services."

  • Although I have NAM, which includes HA, I haven't enabled/deployed HA.  Two of my six APE's came back with "red" alarms under the "Set Up A New HA Server" window after the hotfix was successfully applied.  That shouldn't happen when the other APE's and the main instance show the same view as green for them.  (See below--this condition still exists today)


Although I've noted a bunch of concerns, the end result is that the hotfix ultimately installed correctly.  The only actions on my part were to be unnecessarily concerned about red errors that could be ignored, and I had to manually restart the Main Instance to get past the error shown in the first graphic above.  The hotfix installed correctly and automatically on all the APE's after the Main Poller was restarted.

It took several hours longer than expected, and it seems this is because three of my APE's are further away from my Internet connection.  Their additional distance and latency seem to be the only things I can point at as reasons for their downloads to be so much slower than those for my local APE's.  The remote APE's share a pair of 10G WAVE WAN resources back to my location, and but each runs runs on older VM server hardware, whereas my local APE's run on current UCS chasses with 40 Gb connections to their local core switches.  Bandwidth to the remote sites isn't an issue, but perhaps latency, and perhaps hardware version they run on, might be the reason the install took 30 minutes for my local APE's, and three hours for the remote APE's.

Thank you rschroeder for such a detailed analysis. I can't say for certain what was locking that file, but if it occurs again in the future open Resource Monitor on the machine, go to the "CPU' tab and enter in the name of the file under 'Associated Handles'. This should tell you the process that is locking that file.


As for your polling engines appearing 'down' in on the Orion Deployment Summary section for HA, this may be related to timezones. Ensure that the timezone is set the same on all APEs and matches that of the main Orion and SQL database server. This should be true regardless of the geographic location of those pollers.

Thank you for the info, Jeremy.  I'll work on capturing the hung process next time I see if it happen.

My APE's are all in the Central time zone, and configured that way.  They're not that far apart as the packet flies--just six milliseconds across and back over our 10G Wave, covering the driving distance of 240 miles (one way) between Duluth, MN and Fargo, ND.

0 Kudos

The Red APEs could also be an issue with short name resolution. Ensure that each APE can ping the short hostname of those servers. For example, from the main poller, drop to a cmd prompt and 'ping E-6ATD-SWNPM04'. Similarly, from the 'E-6ATD-SWNPM04' machine, open a cmd prompt and ping the short hostname of your main poller. If either of those doesn't work, then that's likely the reason why it's red.

0 Kudos

Pinging the short name of either server, from either server, works successfully.  The reds must have some other cause.

0 Kudos
Level 12

Going to apply HF2 (currently on 2019.2 HF1), anyone had any issues or oddities during upgrade?

0 Kudos

I had it fail on two of our APEs (in remote locations). I was fighting with it for few hours, pushing retry in the centralized upgrade window, after several tries it installed successfully.

While I was doing that I have contacted support and they advised to do the following if update fails:

In case any of APES fails during centralized upgrade do the following:

- Wait till all upgrades are finished (either successful or failed state)

- Cancel the process on web console and run upgrade manually of the server where it failed

- If you cannot cancel the process then go do Database Manager on HUBUD0728 and run the following query:

update [dbo].[swa_installationsession] set isactive=0

After the query, run installation manually.

Other than that it works without issues.

0 Kudos

I went through the configWizard logs and in my case it was because the NCM EVAL had ended and had issues getting the response back from the database . This was a test instance, so putting a process in place to remove any eval modules in the future.

0 Kudos


I would love to be able to run this update, however i cant seem to get passed the validation checks for various reason that i cannot seem to resolve.

Anyone any ideas as to what i am doing wrong.

Below is the step by step process / output i get.

Step 1.

Step 1.JPG

Step 2

Step 2.JPG

Step 3

Step 3.JPG

We can forget about the first 2 errors - thats the databse backup and HA was still enabled so i can get round these.

The last one regarding no internet conection, well the server DOES have an internet conenction, so no ideas as to why this error is here either.

The next 2 however are puzzling.Checked mismatched MS Updates - ALL servers are patched as far as they can be done, and each machine for speed also have a local hosts file pointing to all IP addresses that it needs to know about.

I have ran the Solarwinds Active Diagnostics and i get the following output when running the OS/.NET tests.

Step 4.JPG

The last error is relating to NCM Job logs and the knowledge base link points me to this article Success Center  however it doesn't tell me how to fix it or what the actual issue is?

So unless i can get past these tests or figure out what's going wrong then i suspect i will have issues with any future updates also.

Any help would be aprpeciated.

0 Kudos

dunky2k It looks like you need to simply confirm that you've backed up your database, and temporarily disable High Availability to proceed. The other two are warnings that can be ignored. As for the other Polling Engine, you may need to install the offline hotfix bundle to that machine without internet access. That can be downloaded from your Customer Portal.

0 Kudos

aLTeReGo​ I use the 'offline installer' by default on my MPE that has internet access.  I have several APE's that don't have internet access.  It is my understanding that using the offline on the main will copy that to the additional servers and will be a smoother experience?  Can you confirm best practice for mixed internet accessible servers (some with, some without)?

0 Kudos

That is correct. However, in this scenario, Hotfix 2 requires Microsoft's .NET 4.8 which is what it's trying to download from the internet. You can install that separately on your own, or you can use the offline bundle to install it for you by running it directly on those pollers. The reason this is not pushed out through centralized upgrade is that .NET 4.8 typically requires a reboot to be applied.

Installed and Ran the wizard successfully in one environment. 2nd  environment, installed and ran the wizard successfully on one server in the HA and wizard failed on the 2nd server which has brought the SW We console down on both servers. Working on it now. But will prob open a case

0 Kudos