4 Replies Latest reply on May 11, 2016 11:55 AM by cfizz34

    Migrating standalone IPAM into existing Orion.


      We have a standalone IPAM box with it's own instance of Orion. We also have another box that has Orion, NPM, NCM, UDT, and NTA.


      We'd like to move IPAM so that it shares an Orion database and web console with the rest of the products. Does anyone have any insight into how we can accomplish that? I'm open to using SQL to move data if that's what's required. I also considered using the Configuration Tool on the IPAM box and reconfiguring the Databases to point to the Orion Database of the other box (they share a SQL server.)




        • Re: Migrating standalone IPAM into existing Orion.

          I know it's a bit of an old message, but I figured I'd drop a couple points onto this one.


          The simple answer is that it's not possible. The Orion databases between the two products have so many overlapping tables and therefore overlapping data that it would be a nightmare to mesh everything together seamlessly. I am not a dba, but I would think that anyone who does SQL for a living would make any excuse to avoid that project.


          That being said, a possible solution would be to export all the subnet data (under IPAM Settings->Manage Subnets & IP Addresses), install IPAM on the existing Orion server, then re-import all the subnet info back using the exported data.


          If you go this route, you may want to upgrade to IPAM 3.0, as enhanced importing has made the task of putting existing subnets in place much easier. At the moment, IPAM 3.0 is in RC, and you can sign up for it here:http://thwack.solarwinds.com/groups/orion-ip-address-manager-release-candidate

            • Re: Migrating standalone IPAM into existing Orion.

              For what it's worth, I did solve this myself. The export/import solution was quite unweildy, since we have 300+ subnets. The solution I followed, which took all of about 20 minutes to engineer and 5 minutes to implement, was quite simple. The existing standalone IPAM and the existing Orion products shared a single SQL cluster. Once IPAM was installed in the existing Orion, I was able to recreate the essential tables. In this case, the existing IPAM was in a DB called SolarwindsIPAM and the existing Orion core was in a DB called NetPerfMon. I used a series of Drop and Select statements to delete the empty tables and recreate them as previously populate. Once done, I restarted the Orion server and voila, all done. So yes, while this is "Unsupported", it wasn't difficult. One important caveat is to make sure that both the standalone IPAM and the integrated one you're importing into are at the same version to ensure identical table structures. Easy with a cursory level of SQL knowledge.


              There were a few tables I skpped, the DNS Server tables, for instance, since I didn't use those features. Some of the tables (AttrDefines, AttributeTypes, Engine, Events, EventType, etc.) didn't need to be moved as they either contained data created by the installer or, in the case of Events and DHCP Leases, would be automatically created as the product is used. Those can be moved if historical data is required.


              Attaching my SQL as an image since the reply thing is bombing, thinking i'm trying a SQL injection


            • Re: Migrating standalone IPAM into existing Orion.

              Hello chmcasmartin,


              This is a nice solution, but not a complete one, because it miss some tables as described in original post (for DNS, Custom fields, ...)


              As this solution does not migrate whole database, it lost connection between Orion node and DHCP server in IPAM.
              Therefore, now when the node (where the DHCP server runs) is updated: the IP address of node and/or Node name.
              The change of these properties will be not propagated to IPAM’s DHCP server.


              You need manually re-create DHCP server credentials, as they are stored in shared tables in Orion core.

              NOTE: The IPAM_WindowsCred table is obsolete now.


              Last, but not least… by simply re-creating the tables with INSERT SELECT command, the auto-increment columns, PK, default values for a new rows are lost.

              The indexes, etc. ... are missing, then the performance issues can be expected.