This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Dev to Live Migration question.

Apologies if this is a dumb newbie question.... but I'm just getting started with this particular product set.

We have a development environment where we are trialling various aspects of the SolarWinds tooling (NPM, NCM, NTA, SAM HA etc).

This gives us a good feel for the product set, and as part of this we are looking to understand how to  move some of the configuration into Live operation.

We have stringent operational Quality Control and Change Management procedures in place, so we need to be able to replicate any customisations in our live environment - without copying an entire database or having to re-type the configurations. Essentially we need to be able to  export then import various configurations - but not the actual individual device/application settings. As in most commercial organisations our systems (dev & live) are air-gapped, so we want to maximise the control of what appears in Live.

For example the types of things that we would need to be ported through to live would be:

  • definitions for Windows User Groups and permissions within SolarWinds
  • Menu customisations
  • application templates
  • Polling configurations
  • etc.

Is there a way to do this, ideally as simple as possible

All suggestions gratefully received - Thanks in advance

  • 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.

  • 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.

  • 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.

    Cheers

  • 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

    Cheers

    Dave#...

  • 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:

    Migrate the SolarWinds Orion SQL database to a new server - SolarWinds Worldwide, LLC. Help and Support

    Best practices for managing your Orion database - SolarWinds Worldwide, LLC. Help and Support  - includes migration notes

    Migrating an Orion Platform Product Installation - Video - SolarWinds Worldwide, LLC. Help and Support

    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?

  • thauma

    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.

  • 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.

    -Marc Netterfield

        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.

    Cheers

  • 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.

    Cheers

  • 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.

    SAM

    1. Templates can be imported and exported - but they wont be auto assigned to nodes, which is a manual activity again

    NCM

    1. Not much - most of the config in the latest versions are stored on the DB

    NTA

    1. Not much - most of it is stored on the DB

    HA

    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