SolarWinds does not allow for DEV/TEST "free" licensing so you have 30 days to play in the sandbox, then rebuild it. There is a product request for this feature/option i.e DEV environment licenses.
Thanks for the reply.
I understand the issue around licensing, and we have appropriately licensed servers.
The question is around the process and tooling to facilitate the movement of configuration/customisation changes through a development lifecycle with stringent change controls.
We will have Development, Integration, Pre-Production and Live environments, and need to migrate authorised configurations through this cycle of environments. As the environments are of different sizes, server names, and address ranges - we can not move the databases as the operational data would be irrelevant.
Basically what you need to do to move from DEV to PROD is just to get real licenses for the products. You can license the modules offline using the license tool. You do this between Orion and the Customer Portal where your licenses will stored. Each license is node locked to the host it's on so there's a little back and forth for air gapped networks like mine but it's pretty easy.
If you are going to move to different hardware or VM's you need to install the same version modules on the new hardware then move the SQL Server database between the two. There are guides in the Success Center for how to do this. It's also pretty easy and if you run into problems just call support.
In our environment being able to control (version control, release management etc.) are critical activities and required for regulation. So moving an entire database is not an acceptable solution
Can anyone answer this question?
Or am I to believe that there is no way to export configurations for menu, view, user definitions along with all the other customisations
1 of 1 people found this helpful
The application templates, that you have created, can be exported (one at a time) from Settings --> SAM Settings --> Manage Templates. You will see the Import/Export option at the top.
But all the other things you mention are stored within the database, and the supported way is to migrate the database and change a few table entries, then run configuration wizard on the new Orion platform.
Here are some support links, for more information:
Best practices for managing your Orion database - SolarWinds Worldwide, LLC. Help and Support - includes migration notes
There will be a way to extract the data, but I suspect it won't be straight forward.
Have you reached out to SolarWinds Support for their assistance?
Almost all of what you are looking for is stored centrally within the SolarWinds Orion SQL Database, so that is why it has been the most recommended option. Initially, I do agree that a Database migration would most likely suit your requirements, as to comply with your security policy would be to delete that content prior to migration.
So if you deleted all the Elements and Polling Credentials then all of the items you requested would still be copied over such as:
- definitions for Windows User Groups and permissions within SolarWinds
- Menu customisations
- application templates
- Polling configurations
Even your Views / Dashboards would remain the same. You only need remove the Dev environments unique settings such as the nodes themselves and their credentials. Removing the Node will remove any application polling but the template itself will remain in your system.
The other option is to use the Orion SDK along with scripting such as Powershell to pull out certain parts of your Dev system and re-create them in your new Production environment, but the Orion SDK isn't a production tool, it is still classified as beta and as such support around it is largely based on community effort with groups of SolarWinds support staff.
3 of 3 people found this helpful
The direct answer being, no, there are LOTS of things within Orion that have no built in mechanism for exporting/importing between systems. I had a conversation with some Solarwinds staff recently relating to this issue and they still didn't see a valid use case for a ton of the things I literally do every day to sync/merge/migrate/replace environments so from their perspective this appears to be a non-issue.
As above, I have to do all of that work directly within the database or using scripts to pull it apart and parse it and the process tends to be pretty tricky, lots of learning by errors as you go.
Good luck, and if you feel like you want help with getting yourself up to speed feel free to reach out. I don't think it's an exaggeration to say that I probably have the most experience in scripting these things for process automation of anyone using Orion.
Loop1 Systems: SolarWinds Training and Professional Services
Thanks for the responses folks. It looks like we will have some interesting times ahead.
Time to start investigating the database structure - no doubt that will be a challenge.
I could give you a few tips which has import / export within solarwinds (I am assuming you have the latest version atleast the latest core or N-1):
NPM (considering this is your base - ideally but never mind you could have any core module as the base)
1. Users/Account - cannot be done
2. Reports - can be imported and exported (both web based and the ones that are created through report writer)
3. Alerts - can be imported and exported
4. Maps - cannot be done
5. Views - cannot be done
6. Custom UNDP Pollers - can be imported and exported
7. Groups - cannot be done
8. SNMP Trap - rules - cannot be done
9. Syslog - rules - cannot be done
10. Node migration - cannot be done
11. Custom attributes - cannot be done, but values can be imported and exported, once you have all the nodes and attributes in place, through bulk
12. Any credential's used like say windows cred (WMI), VM Ware API (cred), Cisco UCS (cred), Meraki (cred), SNMP Comm string etc - cannot be done
What else - let me know, the above things are most generic features which needs to be looked into during the migration that you have outlined above.
1. Templates can be imported and exported - but they wont be auto assigned to nodes, which is a manual activity again
1. Not much - most of the config in the latest versions are stored on the DB
1. Not much - most of it is stored on the DB
You have nothing here that needs to be transferred, this module is used for SolarWinds application failover and needs to be setup accordingly, hence don't bother much about this module with respect to config transfer
Hope it helps
Actually, migrating views can be done with the right script and the Solarwinds SDK.
1 of 1 people found this helpful
Just shamelessly self promoting, I published this to Thwack last month. After my vacation next week I'm going to write the tool to import dashboards from XML files to make it easier for the community to swap resources/custom queries/entire dashboards
I was able to migrate the following things with the API:
Nodes (WMI Credentials have to be set up manually first)
so if you ever run into something where you need those things to migrate drop me a line.
There is a great portion that you can "copy over" utilizing the API of solarwinds. However this is custom scripting.
I have done this in the past for a few customers who wanted to start fresh with a new database.
However there still are certain things that you need to build from scratch when you want to start with a fresh database.