This is not something I have ever tried to do. Support may be able to provide you with some options on how to do this.
Do you have another server you can use to test on?
You could run an all tables backup and restore it on to another server with the correct directory structure to see if it retains the directory structure.
You could setup another NSM with the correct directory structure, add it as an secondary in an MDR pair and it should replicate with the database on the primary. You could then reset this to stand alone and let it take control of the sensors.
You could also try running the install program again and specifying the F drive as the target directory and see if it will upgrade your database to the correct directory, but this may just leave you with multiple installs and create more problems.
Peter's recommendations are solid. Another option though if this is a new install then it is likely you haven't generated much data yet from the sensors so uninstalling and re-installing the NSM software would be the simplest way to accomplish what you want to do. If you have already set up a lot of sensors which have generated alerts that you need to keep, then follow the backup recommendation Peter mentioned and you can export the sensor configurations from the original NSM install store them, then import them into the new installation.
Not sure if it's too late to recover at this point, if you cannot restore the backup. I assume you had a step between 2 and 3 to re-install the NSM first? If so, it may be an issue that the drive lettering isn't matching to what it had before.
What I would have suggested (sorry, it's a day late) is:
- Set up a secondary server, at least temporarily; usually easiest to use a VM.
- Install NSM on that VM of the same version as the one you want to fix.
- Make it an MDR pair with the other one. Let the database replication take place.
- Force a DB replication, then make the temporary one a stand-alone again (break the MDR pair)
- Then uninstall, clean the directories, etc. of the broken one.
- Reinstall NSM the way you want on that one.
- Make it an MDR pair again
- Replicate the DB.
- Make the fixed one a stand alone again (break the MDR pair)
Since an MDR device is part of the NSM application, and included, I recommend it for redundancy for use cases like this one. It can be a benefit to have it for NSM upgrades, migrations of servers, upgrades of servers, etc.
When running an 'All Tables' you should stop the manager service and run the backup using the dbadmin tool. You can run an 'All Tables' backup from withing the manager but they are normally missing information and fail to restore.
After uninstalling the NSM software from your manager did you manually delete the remaining files that were not removed by the uninstaller?
Did you re-install the same version of the NSM software that you used to create your backup?
When you run the backup you should have gotten two files, the jar file contains the information about the backup and the .dmp file contains the actual backup info, make sure they are in the same directory when you try to restore.
When you are using the dbadmin tool on the DB Restore tab you select the .jar file and click on restore.
How big was the backup file?
After running dbadmin.bat and browsing jar file to DBRESTORE i was able to get my configs back, thanks for your support.