[Solarwinds Orion 10 3 Keygen Free
Julieann Rohde
I'm sure you've read all the articles in the Success Center and even contemplated that one method you read about doing this with "Zero Downtime". Well instead, I'm just going to tell you what I did and hope it at least helps a couple people who might be currently pressured into upgrading. *cough*
Start by powering down that NTA server of yours. You wont need it. Orion version 2020.2.1 now creates a new NTA database on the same SQL server that the Orion database gets placed on. This will happen during the configuration wizard for the 2020.2.1 install.
At this point, you should now have (2) Windows 2019 Servers. The one with SQL 2019 is setup and ready to go and another that will be your new SolarWinds Orion server, which is just sitting there waiting in anticipation.
Log in as the Local Administrator on the new Orion server and run the installer. DO NOT PROCEED WITH THE CONFIGURATION WIZARD. We will do this when it's time to cut over. Just cancel when you get to this step.
Once the backup is done, go ahead and copy it to your new SQL 2019 SQL Server and restore it using the same link in the last step. You will no longer need that old SQL Server of yours. (For SolarWinds at least...)
Once the database has been restored, you will need to select the newly restored database on your new SQL 2019 server an execute the following query, replacing 'Server 1' with the NetBIOS name of your OLD Orion server and 'Server 2' with the NetBIOS name of your NEW Orion server:
Just to recap, we've deactivated our licenses, backed up our database on the old server, restored it on the new server, updated the databased to reflect the NetBIOS name of our new server, and powered down the old Orion server.
Now on your new Orion server, go ahead and start the configuration wizard I told you to skip earlier. Follow the steps on the configuration wizard and select the option to use an existing database. Point it to your new SQL 2019 Server and use the SA account to create the initial connection. The configuration wizard will then ask if you want to create a new account for SolarWinds to use instead. Please do this and do not actually use your SQL SA account.
The configuration wizard will now prompt for the same thing, but now for the new NTA database. Choose to create a new database for it on the new 2019 SQL server. Use that new account you created in the last step for accessing the Orion database.
While I can't guarantee the same process goes as smoothly for everyone else, especially if you have multiple polling engines (please see ahbrook comment below for help with APE's) this process only took me (1.5) hours to complete after I had already pre-staged everything along side my old environment.
Should for whatever reason you need to fall back, all you will have to do is power on the old Orion server and reactivate your licenses. (Assuming you haven't changed the hostname and IP of your new Orion server to match. This is why I created a CNAME and tested my access to the portal first.)
This is good in case you're not on an affected version and someone still thinks it's smart to upgrade to 2020.2.1 HF2 right now! I'm not sure why anyone would think this is a good idea right away but... that's just me.
My intention with this post was specifically help anyone that might be under extreme pressure to get to the latest version. I'm sure we can all agree this was not on our Holiday wish list, especially mine, but felt I should at least offer what I can for anyone who has not had to do this previously.
In this scenario, are you leaving the agents installed on your managed nodes? I've not seen much guidance on whether or not they would be compromised as well.. We're estimating that we will have to completely uninstall and reinstall our agents, and I do not know how our database would like that -- if we decide we are keeping our DB and it isn't infected.
When I performed this upgrade / migration, I completely left our SolarWinds agents as is on the servers they were installed on. Once I created the CNAME record of the old Orion server that points to my new one, the agents checked in and updated their version of the agent software automatically.
The only thing you would still need to do after is modify the agents settings from control panel on each server that has it installed, so the hostname or IP now points to the new server name. That's assuming you're not eventually changing the name on your new Orion server to match the old one. Then you can skip having to do this part.
On Friday, we got the call from our security office that we were safe to proceed with a migration scenario. I used this thread as part of my work to develop steps, and learned a few things in the process that may be helpful for others.
Main poller running 2020.2.0 on physical hardware
Additional polling engine running as a VM
Production database running on a physical server
Test main poller running as a VM.
Test database running as a VM.
Wipe and rebuild the physical machine, giving it a new name (app02) but the same IP as the previous server
Build a new APE, giving it a new name (ape02) but the same IP as the previous server
Build a new test main poller, giving it a new name (app02-t) but the same IP as the previous server.
Changed the passwords that Orion accesses the databases with, but left the database servers more or less alone.
- The Test environment would not see the Test database. This turned out to be because firewall rules that allowed inbound communications were lost on the DB. We don't know why at the moment; I suspect they were pulled out due to an abundance of caution.
- Eventually we moved app02 to a unique IP address, and this allowed the configuration manager to run and the website to work, just extremely slowly. It sometimes hung trying to access the orion agent to download it.
- To finalize cleanup on prod, I needed to remove the now-useless extra poller (the extra app02 that was created by my mistake), repair the license using the steps outlined above, and then re-apply the licenses we deactivated before starting. We also reset the IP back to its original, and ran the configuration wizard again.
After taking these steps, production looked good - the instance was running, I could see all of our nodes in the maintenance mode we put them in, and security was working as expected. The agents were not checking in, however, but we are waiting on networking to put in the CNAME to see if that fixes it.
As far as test goes, the process was simpler because we had tested in prod... as you do. (Given that prod was physical and was not having the database access issues, I focused on it first). For test, I was also able to go in to edit the database and rename the references. In its case, the license seemed healthy, but it did not work and allow us to manage nodes until we deactivated and re-applied all our licenses. I also needed to clean up the extra polling engine that it thought existed.
If you have a multi server or HA setup, it is extremely important that you go in and check the database references in between installing the new software and running the configuration manager. There can only be one main poller, and likely the system still thinks it exists if you are using the same database servers. It doesn't take much to check this, so better to be safe than sorry!
We're still not 100% up, but we are looking better for the holiday break. I am super grateful to this thread and other places that have been sharing tips and tricks to getting things secured and back to full operational status, and that's why I wanted to post this - to help others who may follow in our footsteps.
To add to the above, I have added a page / tab in the left hand side popout called "Orion Map" for the group, and I want to display this specific map, for this specific group, and only in this group. As a bonus, it would be nice if said map was available from any node in this group without any extra effort, but not essential.
At present, if I select map ABC, then no matter what group I go to, I only ever see map ABC whereas I want to be able to see the map for that group - so ABC map appears on ABC, XYZ map appears on ZYX page and so on.
The issue that we have is that the orion map tab dynamically populates each time it is selected, this throws all of the objects on screen in a random order, we can re-arrange this to reflect actual but we are unable to save that view.
If I may, your ask essentially contains 2 specific details that are important to consider. Today, in reality, 2 different types of Orion Maps exist. There are maps created in the map editor and saved, similar to what you described in your case (Map ABC), as well as the contextual map sub-views which are automatically generated. The Contextual Sub-View maps are dynamic and it is not currently possible to manipulate layouts, icons, etc... and have those changes persist.
One of the difficulties we have right now is how Groups function in that all group details pages share the same widgets, therefore adding an Orion Map widget and selecting Map ABC to be shown would result in MAP ABC showing up on every Group Details page. This is obviously not ideal. As mentioned in this thread, which even linked to one of my old posts, there was a way to overcome this from Atlas maps but is not available in Orion Maps.
Unfortunately making changes to Groups is a significant undertaking, and we hope to improve upon this in the future. I love the idea of a contextual widget of a specific map for all mapped members and something I would love to get into a future release also.
For now, the best option would be to create a custom view of entities and widgets which could include other metrics and a map. You can alert and report on maps similar to groups including membership availability etc...
Yea, that's one of the reasons we don't want them to get rid of Network Atlas at this point, there are some things you can do in it that you can't do in Orion Maps. We are doing pretty much exactly what you want in Network Atlas right now, displaying a "per group" map on each Group page. Simply add a "Map" resource type and instead of selecting a map, go to the box that says "Map name format" and choose one of them, we choose "Group $Caption". Then, lets say your group name is "Foo", simply edit a map named "Group Foo" in Network Atlas and save it, and that map will show up there, while for group "Bar", the map named "Group Bar" will show up.
795a8134c1