2025.1 Upgrade Status

We just upgraded our on-prem self-hosted SWO from 2024.4.0 to 2025.1 successful without any "serious" issues that would require us to revert to snapshots and a Database restore.

One issue we have encountered/currently troubleshooting is in regard to WPM transactions. We have around 114 WPM monitors, after upgrading to 2025.1 we had 13 of them go into an "unknown" state after about 30 minutes, if you force the transaction to play it appears back up after 40-60 seconds, not the typical 5 minutes it takes to replay the transaction, which is odd.

Debug logs on the WPM players in question do not indicate any errors (typical minor errors in the logs), although if you look at the Orion.SEUM.Transactions table most of them have a LastModificationDate of 2/18/2025 around the time the main platform was upgraded. If you look at 13 of them, they have a date of 1/1/1753 (pretty funny)

We are in the process now of re-creating to see if this resolves the issue. Also, I am not going to waste supports time, my companies time, or my time with this issue.

Find more posts tagged with

2025.1

wpm

Accepted answers

All comments

jvb

Thanks for the info. I have asked the engineering team to look and see if we can determine where that very odd (old) modification date is coming from.

kencancast

thank you JVB appreciate it.

kencancast

Troubleshooting this yesterday found this isolated to one of our 6 WPM players, 4 of them are 2019 2 of them are server 2022. If you move recordings to the 5 other players and rinse and repeat for all 5 players and wait 30 minutes they stay up for both the 2019/2022 nodes. Very time consuming.

This is great, this issue is isolated to ONE of the 2022 WPM players. Looking at the player in question, validated:

GPOs match across WPM players
Ciphers match across WPM players (yes we use IIS Crypto Best Practice) to harden the SolarWinds servers since Microsoft is lazy and leaves depreciated security in place. And we have security auditors that love reviewing issues with our SolarWinds setup.
WPM player settings match maxPlaybacksPerWorker="2"/numberOfWorkerProcesses="12" across the players.
None of our SEUM accounts are in the Local Administrators group, this is an issue with our security team. Everything has worked fine this way.
Logs show playback and OK in the logs.

WTH. the 6 remaining transactions on the player in question show unknown.

The Orion.Transactions table shows a few transactions still with Last ModificationUTC to 1/1/1753, cool that is awesome.

Ok, Lets get medieval we have a snapshot, lets uninstall the WPM player (had a hard time locating documentation/took snippets from multiple versions) this is what was done:

Move transactions off to other players
Remove the location from WPM settings
Uninstall
Rename SEUM in C:\ProgramData\SolarWinds to SEUM_old
Reboot
Remove All SEUM accounts (Call from the SOC, oh well)
Reinstall manually
Add the WPM location/Add existing location since player was already installed, tested ok

Note: Not a big fan of how to locate product troubleshooting documentation, most of the time documentation is outdated, or documented without the correct/current platform version. Very time consuming.

Ok, now that the player is reinstalled, assigned transactions, waited 40-50 minutes, still unknowns. WTH. the transactions assigned to this player still appear unknown. Ok, so it is not the player. It has to be in the main platform/database.

Ok, lets dive into the DB, took a look at the SEUM_Agents table. Everything looked good except for the PollingEngineID. Now I understand under the WPM player location advanced settings you can set the Player to any Poller engine you like that is different from the Player polling engine in nodes table.

So I decided to update the PollingEngineID for the WPM player to match the Polling Engine it is assigned to under Manager Nodes (Nodes table)

Restarted the WPM player service on the WPM Player in question.
Unmanged/Remanaged the transactions
Noticed that they immediately did not go to green status after 40-60 seconds
Took about 5 minutes and they started coming up

Great, took a look at the SEUMTransactions table no longer see transactions for 1/1/1753, that is awesome.

So in the end, setting the Polling Engine Within the Players location settings to match the Poller it is assigned to in the nodes table somehow allowed communication from the Player to the platform to allow the tables to update and the transactions to stay up assigned to the player.

I don't know if it is "best practice" to keep the WPM player locations Poller the same as the Polling Engine assigned to the node.

On another note, some of the job engine/scheduler components for the Orion Server SAM monitors have been alerting more on 2025.1

I am guessing that in 2025.1 since the polling capacity has been increased, this would make the values invalid. It would be nice if there was documentation somewhere that outlined acceptable values for the Performance Counters for the Orion Services. OpenAI is not much help outlining what they should be.

michal.kalina

Hi, to add a note regarding from where '1753-01-01' date comes from. Basically, it is the lowest possible value that can be set for datetime type used by LastModificationUTC column. Additionally is used by the table definition as a default value for that column which means that anytime something adds new data to that table (but without specifying the value for that column) for the first time that value will be set automatically by DB Engine. The same approach is used in multiple tables.

kencancast

michaal.kalina - Appreciate the information.