which part of Solarwinds must I use to make this install at the new SQL server? does anything need to be re-installed at the Orion server or is it all done at the SQL server?
While you will move your database, you will have to stop all the Orion services.
Once the database will be available at the new location you will have to run the Configuration Wizard to connect it to the new database location.
Start > All Programs > Solarwinds Orion > Configuration and Auto-Discovery > Configuration Wizard.
Select Database and follow the steps. You will probably have to re-create the Orion SQL account (SolarWindsNPM).
does anything need to be re-installed at the Orion server or is it all done at the SQLserver?
Nothing has to be re-installed apart the Database part of the configuration wizard.
will my maintenance contract cover assistance from Solarwinds Support for this move?
Yes we will help if you get any issue during the migration.
Here is a Tutorial that should help you prepare the migration: Orion Database Migration
If you are only moving the database to another server, there is no need to activate/deactivate any licenses.
The license belong to Orion (plus the other modules), and as per what you said Orion stay on the same box, so no need there to bother with the licenses. As said by Dobbs, run the configuration wizard to connect Orion to the new location of the database and it will normally restart all the services for you.
Personally, after doing backup, I took the DB offline on the original server.
COPIED the DB to the new server and added DB to the new server pointing it to .mdf file (ensure .ldf goes with it).
with my issue today it turned out the NTA files have to be manually renamed to match what is embedded in the .BAK copy.
the RESTORE sees all files inside the .BAK as NETPERFMON and not as NETPERFMON_FG1..._FG2...etc.
after renaming each to match their original names then i was able to proceed successfully with SQL RESTORE.
one other gotcha was with the account SolarwindsNPM - i ended up having to create something entirely different for this to work successfully with my Orion server.
but i am seeing issues with NTA 3.1 after this move - i guess i need to re-apply the last update again????? was there a hotfix for NTA, i don't remember??? anybody know???
...follow-up on the NTA issues...
it seems all i had to do was re-publish those NTA Resource Views again which i already had in NETWORK SUMMARY view and they started working again. i don't know why but that was the fix...
Hi Yann and others,
I am planning a move of my db as well: move it from the NPM-box where it is now, to a dedicated machine that just runs SQL and nothing more. My Orion-config consists of the following:
What I have seen and read, is that NPM, APM and IPAM all use the same database: NetPerfMon. NCM uses a database of its own: ConfigurationManagement. Also, I have seen two SolarWinds database user accounts inside SQL (2005 SP2, for the record).Am I right in assuming that:
- NPM SL500
- NCM SL100
- APM ALX
- IPAM SLX
Is this correct? Anything else to take care of, apart from what's mentioned in the docs and here in the fora?Thanks in advance,best regards,Rene
- I'll have to run ORION's Configuration Wizard to configure NPM/APM/IPAM to use the NetPerfMon-db on the new server, and then
- I'll have to run NCM's Configuration Wizard to connect NCM to the ConfigurationManagement-db on the server
Moving the database is a straightforward procedure and is already documented in the following resource - http://www.solarwinds.com/support/Orion/docs/MovingYourOrionNPMDatabase.pdf
Once the database has been migrated from 1 server to another, you just need to re-run the configuration wizard to connect to the new database source.
The server I was hosting both the web console and the database has had the database moved to faster hardware.
In fact we couldn't be more happy with the database performance at the moment.
However even thought the web console is available from all of the network team's desktops. I can not login to the server web console on the server. It just returns to a blank login request. Has anyone else observed this before and what was the fix?