Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials

Migrating IPAM or UDT to a new server from an integrated installation

I've seen some posts on Thwack and some in the support Center about "Migration of X application to a new server", and I wanted to do it for IPAM and UDT (them them off of my server with NPM/SAM/UDT/IPAM/NCM all installed together) for a few reasons:

- IPAM doesn't really share a lot of integration with the other products, and the Network team primarily uses it. It would be a good standalone installation as it scans and this work could be offloaded to an independent server. Scanning rate could be increased.

- UDT does share a lot of integration with the other products, but it looks like it would be a good standalone system since another team primarily uses it. It could be turned up to pull/scan more data at a higher rate if this work could be offloaded to an independent server.

- IPAM and UDT don't support Windows 2016 (yet). I want to get all the other products on Windows 2016, and I don't want UDT/IPAM to be the hold up.

- With IPAM and UDT out of the core system, upgrading all the apps is a little easier (less dependencies,etc.) and maybe I can free up some resources on my old server.

I have my database on a single, independent server that all products are sharing. I ***DO*** want to keep the database intact as-is ( i.e. I don't need the database/data for IPAM/UDT moved out onto a new database)

From everything I'm reading, this looks like it's not too hard to do?

- Update IPAM/UDT to a known version (hopefully latest that can be supported on the DB/OS)

- Install the "same version" of IPAM/UDT as above onto a separate servers (I want them on separate VM's). Do not run the config wizard after the install.

- Deactivate the IPAM/UDT product license (from Web UI, or Support Portal)

- Shut down the "old" services supporting IPAM/UDT on the old server- Start up IPAM/UDT on the new servers.

- Activate the IPAM/UDT licenses on the new servers.

- Done. Possibly uninstall IPAM/UDT on the old server?

The only gotcha I can see has been:

- There may some rows in the Orion database related to pollers? that need to be deleted as the Config Wizard may fail on IPAM: IPAM moved to another server, problems...

- There appears to be a cert. to move to the new server for UDT: Move SolarWinds UDT to a new server - SolarWinds Worldwide, LLC. Help and Support

Has anyone done this, specifically for these apps? Any issues or gotchas you know of? Also: I can't seem to find an "Move IPAM to a new server" guide like I found for UDT.

Thanks in advance!

Find more posts tagged with

Accepted answers

All comments

pwv

Hi,

Fo IPAM:

Migrate SolarWinds products to a new server with a new IP and hostname - SolarWinds Worldwide, LLC. Help and Support

You can also check the active servers with a DB-query:

SELECT * FROM [dbo].[Settings] where SettingID like '%CW-ActiveInstance-%'

For UDT:

Moving SolarWinds UDT to a new server

tigger2

Update:

I migrated both IPAM and UDT to their own servers.

Basically, it appears the instructions above to "Migrate to a new server/IP" are the ones to use, with the added step of "when Orion is shut down, make a copy of the database to use for the new system"

I ran into a few "gotchas". Since UDT/IPAM have a base of Orion Core/Platform to them, a lot of your settings come over that you may have thought would not. Examples, if you just follow the migration docs, of what your migrated system may have in it that you may want to try cleaning up:

- All your alerting rules migrate over, and are *active*, assuming you left them all on when you shut down and copied the database.

- All your nodes are migrated and "active" for monitoring, assuming you left them all managed when you shut down and copied the database, so your alerting rules above will start triggering. For something like IPAM you would want only a few domain controllers/DNS servers being set up and monitoring.

- All your reports get migrated, so you'll have reports in the system as "default" that you may have trouble removing that go to other products (NCM, SAM, etc).

- All your views/menubars, etc get migrated, so many will point to products that were in the old system. You can just remove them without issues.

- All user access rights are migrated (makes sense), but (I believe) if their views were set to apps that are not in the new system ( like SAM views) then these get "deleted" or set to "none" in their preferences.

If you don't want to go to a lot of trouble, I'd suggest thinking about doing these things

Some time before migration:

- Make a custom node property (like a Yes/No/Boolean, something that defaults to "false") and set it to "yes/true" on the nodes you want to keep in the new system. This is so you can filter them "out" when/if you want to delete all the other nodes in the new database.

Immediately before shutting down Orion to make the DB copy (because I could not find a SWIS/SQL query to do it after Orion is shut down):

- Turn off any alerting rules that are likely to alert for "nodes down" or "polling issues" if you have created any. Things that would alert many people or call oncall groups/people, alert people who would be vocal about a false alert.

Immediately after the migration, in the new system:

- Set *all* nodes (except the ones you flagged above to keep) into maintenance mode (or delete them) via the "settings -> manage nodes" page since you can filter on the custom node property you set above to get all the nodes you don't want int eh new system.

- Set all alerts in the new system to "off" if you have hundreds and there are ones that may alert unnecessarily. I had some SWIS/SQL ones for "node polling stopped" that started going crazy, so good to shut those off ASAP.

- Delete all alerts you don't need anymore, turn on the ones you want to keep.

Note: Some services may install on the new, standalone system, but may not be supported as "running" in the Orion Service Manager. I had the SNMP Trap service and Syslog services do this.

Note: Since many views stay the same, I found it helpful to change the color styling of the UI to something very visible/different from the original as a visual cue (mostly for myself, the admin)

Note: I found most users of the integrated system didn't need to access the new system (a reason we moved it to a standalone server), so it was a *great* time to re-evaluate app access and clean it all up/lock it down.