IMC Data Base Change

[JasonL1]

---

@LindsayHill wrote:

Are you looking to dump the DBs from one server, and restore them to another server?

I haven't tried it, but you could probably shut down iMC, migrate all the DBs, and set up all the users. Make sure you give the users the same password.

Then edit C:\Program Files\iMC\deploy\conf\dma.conf, and C:\Program Files\iMC\common\conf\server-addr.xml

In those files, change all the references from your old server IP/hostname to the new name/IP.

Then restart IMC.

If you are creating the new users in the new DB, and you don't know the passwords used for each of the user accounts associated with each DB, use C:\Program Files\iMC\deploy\pwdmgr.bat - it will tell you what the passwords are.

I don't know for sure if this will work, but it would be straightforward enough to test. Since you will still have your existing DB in place, you can easily roll back.

---

This is pretty much dead on, how the process works.

[kortemi]

Thanks, Lindsay

Good suggestions, but alas, they did not solve the problem.

First I tried the change the name of the instance to the tag "JDBC_INSTANCE_NAME". That did not do it.

Then I tried your ("very good, why did I not think of this myself") suggestion about doing a trial install. Well, that took me all day (first, install yet another SQL instance, then install the SQL Management tools, then try the IMC installation). But, despite several (a lot) tries, I was unable to get past the first screen of the IMC Custom install - database connectivity. Selecting SQL Server, the Instance name, the sa account and pw, server IP, and port 1433 (and configuring the SQL server instance according to the HPE Intelligent Management Center v7.2 SQL Server 2012 Installation and Configuration Guide), the IMC installation would give me the error "Unable to connect to the database".

I am beginning to suspect that there is a serious flaw in IMC code, and that it's just simply unable to connect to a named instance....

(and yes, I had actually done the backup and restore of the databases, setting up the IMC db user accounts and their pw's to what they were, etc).

So, now I thought to try one more thing, setting up an SQL 2014 Express on the actual IMC server itself, maybe that would do it - at least then I'll be able to set it up on the default instance...

[JasonL1]

Kortemi, 

Are you using the same flavour of SQL and IMC on both sides?

[kortemi]

Yep, all are the same. In fact, the new test SQL instance was on the same server, just an additional instance.

[LindsayHill]

---

@kortemi wrote:

First I tried the change the name of the instance to the tag "JDBC_INSTANCE_NAME". That did not do it.

I had been thinking of this line:

    <var name="INSTANCE_NAME" value=""/>

Not this one:

    <var name="JDBC_INSTANCE_NAME" value=""/>

But it was just speculation, I don't know for sure.

I am beginning to suspect that there is a serious flaw in IMC code, and that it's just simply unable to connect to a named instance.....

---

According to the 7.2 manuals, IMC should be able to use a named instance, but I can't confirm it as I haven't tested it myself. These days I mainly work with iMC on Linux with MySQL, as it's easier for me to automate.

[kortemi]

Ok, thanks, Lindsay. I'll try that one then (missed it somehow, must be tired or something)

[Pack3tL0ss]

There is currently no supported 'easy' way to migrate IMC to a new DB, DB port, instance etc.

*The below is from memory, is certainly not in exact order... don't use it as a cook-book*

There is a process to do so.  It involves configuring a Temporary IMC server (doesn't need licensing, it'll run in eval mode).  The Temp IMC should be installed to match the Real IMC (same version, same modules, same patch levels), but it is installed against the new DB.  Database is backed up from Real IMC and restored on Temp IMC.  Some key files are coppied from Temp IMC onto Real IMC.  Temp can be de-commisioned and Real IMC should be pointing to new DB.

The reason for this is that IMC creates a file during the install: c:\windows\imc-reserved (or something very close to that - from memory).  That file includes a bunch of information relating to the database (IP, instance, port, credentials, etc).  The file is hashed so you can't manually edit the file.  It is used during upgrades or the installation of a new module.  If you've moved the database it's possible you have an IMC system that seems to function correctly, but when you go to upgrade it will fail as that process references that hashed file.  I believe it's also referenced in other places, the environments tab in the DMA is likely one of them.

If you've migrated and find yourself in a pickle, you can either role everything back to the backup you've hopefully taken so it's pointing to the original database.  Then follow the process to create the temp IMC etc.  OR you can contact support, they have a tool that allows them to de-crypt, edit, then re-hash that file which hopefully would rectify the issue.

I'm hopeful that we will have a migration utility that scripts this and removes the need for a temporary server, but no commitment yet.

Hope that helps,
PL

[kortemi]

Thanks, PL.

This is getting interesting. I thought I'd give Jason's document a try (it's almost the same as another document I've seen, but with some additional info), and so I tried to installa a TEMP IMC installation on the SQL Server where I want to host the databases.

In this document the description reads:

How to change iMC local database to remote database server：

Scene: A customer install iMC and database on server A （IP：192.168.1.114）, now he want to only move database to server B（IP：192.168.1.133）.

Version: IMC 7.0

Restriction: Install IMC platform and all modules in same server

And the process is to

1. stop IMC on Server A
2. install SQL on Server B
3. install IMC on server C (a new TEMP server), pointing to the SQL on server B
4. After IMC installation, copy 2 files from Server C to Server A (server-addr.xml and instinfo.txt)
5. Start IMC on server A
6. Shut down Server C and remove SQL on Server A

BUT, when I tried to install IMC on our SQL Server, the installation (selected Custom) fails on the Checking Database Connectivity - even on Localhost.  AND IT FAILS on both named instance and default instance with the message "Connecting to the database failed. Make sure that the database is running normally and you have input correct login information".

This is getting curious. I'm trying to install ICM v7.2 E0403, so I'm starting to suspect that this version of IMC setup is broken.

So, now I'm considering maybe dropping back to v7.1  for the TEMP, just to see if that would solve the problem - and enable me to follow the process in Jason's document.

[kortemi]

Right, there goes that theory....

Tried with 7.1 E0303, and exactly the same result "Connecting to the database failed".... AARGH!

And this is on the SQL Server itself....

I've edited the SQL TCP/IP and Named Pipes settings, firewall is off (all), I even created a new 'sysadmin' user.... No luck.

And of course the setup does not log anything in the Windows Logs, and I cannot find any log files that the setup would be logging to...

[JasonL1]

I recieved the same error a few minutes ago when trying to install a few new modules after I upgraded to 7.2 here at work. I fought with it then remembered, I turned SQL services off on my main IMC server which, is where IMC was trying to create the new databases.

Now, I need to figure out how to make the installer allow me to change the database location from the IMC server to my database server.