Everything was working fine after a DB server change, now we are getting ”Server Muted” login denied error with ALM11

Question ID: 104712
0
0

A few months ago, we migrated our project DB’s and qcsiteadmin from our old instance of SQL-Server 2005 to SQL-Server 2008. We were using SQL-authentication on both servers, same "td" user/password, and even ran the SQL "Exec" commands to "fix" the "td" user after copying our DB’s.
After running for a few months, all of a sudden, we get a Server Muted error and a stack trace mentioning "login denied".

What is happening… it worked just yesterday?

Marked as spam
Posted by (Questions: 185, Answers: 13)
Asked on November 26, 2012 10:30 am
13 views
Answers (9)
0
Private answer

Have you tried confirming the ''td'' user password by directly logging into the SQL-Server Management Studio tool from your QC server (ODBC would work in a pinch)?

Marked as spam
Posted by (Questions: 3, Answers: 466)
Answered on November 26, 2012 10:32 am
0
Private answer

Just as a test, try doing the same when pointing SQL Management Studio (or ODBC) to the OLD SQL-Server and login as ''td''.

Marked as spam
Posted by (Questions: 3, Answers: 466)
Answered on November 26, 2012 10:34 am
0
Private answer

So, it works with the NEW SQL Server but not with the old one.
I am not suprised since our DBA probebly re-purposed the old SQL-Server instance recently.

How would that have anything to do with it? We migrated everything over and it worked.

Marked as spam
Posted by (Questions: 185, Answers: 13)
Answered on November 26, 2012 10:38 am
0
Private answer

What I think happened to you is that since in QC the PROJECTS point independently to their corresponding DB (via connect string, DB name and ''td'' user password in the DBID files), they were likely all migrated just fine.
The qcsiteadmin_db was also migrated in the same fashion as the project DB's, but to change how QC points to it, you need to change the connect string in a file called SITEADMIN.XML, then re-deploy QC.

Do you remember doing that?

Look again at the DB Connection String /URL in your SITEADMIN.XML file and compare it to the one in the DBID.XML file for one of you recently working projects. If the one in SITEADMIN.XML is still pointing to the older SQL-Server, there is your problem.

Marked as spam
Posted by (Questions: 3, Answers: 466)
Answered on November 26, 2012 10:45 am
0
Private answer

Look here for SITEADMIN.XML to modify [default location]:

C:\Documents and Settings\All Users\Application Data\HP\ALM\application\20qcbin.war\WEB-INF OR

C:\ProgramData\HP\ALM\application\20qcbin.war\WEB-INF

Look in your ''repository'' path for the project DBID.XML file(s) [default location]:

C:\Documents and Settings\All Users\Application Data\HP\ALM\repository\qc OR

C:\ProgramData\HPALM\repository\qc OR

c:\Users\All Users\HP\ALM\repository\qc

Marked as spam
Posted by (Questions: 3, Answers: 466)
Answered on November 26, 2012 10:50 am
0
Private answer

OK, that was the discrepancy.

We have made the modification to the DB CONN STR (DB Connection String) in the SITEADMIN.xml file, now what?

Marked as spam
Posted by (Questions: 185, Answers: 13)
Answered on November 26, 2012 10:58 am
0
Private answer

Now you re-deploy.
Assuming you are using JBOSS (instead of Weblogic or Websphere),
This is easily done from the Start Menu under HP ALM Platform / Deploy Wizard.

Follow the defaults and allow it to start JBOSS at the end and you should be good to go.

**WAIT...**

**A WORD OF WARNING,** though: Try to get yor DBA to re-migrate the qcsiteadmin_db from your OLD SQL-Server to your NEW one (and re-run the td user fix EXEC commands as before). Have him choose the last backup made from just before he disabled the ''td'' user or SQL instance (probably a few days ago).

Since your QC/ALM instance was still pointing to the OLD SQL-Server instance all along, any new users, project changes (like migrating them to a new SQL server instance), etc. are not in the copy on your NEW SQL-server. I hope they did a backup.

Marked as spam
Posted by (Questions: 3, Answers: 466)
Answered on November 26, 2012 11:07 am
0
Private answer

Thank you for your insight.
The DBA does have a backup.
As it turns our they only disabled the ''td'' user on that SQL-Server just the other day and that was when the problem started.

They have notes on the migration process and will complete it (again) soon for our qcsiteadmin_db.
After that, we will re-deploy via the wizard.

What a pain we missed the siteadmin.xml change a few months ago.

Marked as spam
Posted by (Questions: 185, Answers: 13)
Answered on November 26, 2012 11:12 am
0
Private answer

All is well now... thanks so much!!!

Marked as spam
Posted by (Questions: 185, Answers: 13)
Answered on November 26, 2012 11:56 am