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.
1 of 1 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.