Lately, I’m having a strange problem when I try to login to the CMC. After entering the username and password (even as Administrator) I get an error: Unable to connect to cluster @BUSOBJXI03.WEATRUST.COM to retrieve updated CMS member list. Logon cannot continue.
I then immediately try again and the login is fine. I’ve found that if I logout and then try logging in again, there does not seem to be a problem, but if I stay logged out for a while (few hours or more), I face the same issue again.
did you get any answer to your issue ?
I got the same problem. Everytime the CMS is restarted the first user who trys to logon to the CMC receives the errormessage
Account Information Not Recognized
Unable to connect to cluster @“Correct Clustername” to retrieve updated CMS member list. Logon cannot continue
The following logons with same user and password just working fine and this error don’t occure anymore till next CMS restart.
regarding this issue I monitored a funny manner yesterday.
I opened a case for this at BO some days ago and they ask for CMS logs. As I activated the logs (-trace) and tried to reproduce the error it worked wonderful without any problems. After deactivating the logs again… same issue like before…
Logs activated = No problem
Logs deactivated = Problem
BO is targeting the cluster setting , but I doubt it as if there would be a problem with the clustername settings, the login shouldn’t work generally. I assume it has something to do with response time at the first login, as because of the logs the response time is longer which means the cluster got more time to answer… This is just a guess and I have no idea how to prove or test this.
Also a funny thing… I got this problem in our two system environments (development and production). DEV is running in an VM environment, PROD is running on real boxes…
No, never got the problem resolved and it still happens. I had talked to tech support about it and they didn’t have a clue. As for now, it’s something I just put up with.
our environment runs on Win2003 server and the DB is Oracle 9.2 and runs on a own DB-server.
I guess it has something to do with the connection, like the CMS is to slow to respond on the first request. As when the traces are on the connection stays longer and gives the CMS enough time to respond…
Total guess…
One thing I noticed is that when hardcoding the port numbers on the individual services, then I was able to login (only sometimes however) from the server after the restart of the CMS Service.
I was at a training class last month (Administering Servers), and ironically, even in the training facilities controlled environment, they had the same problem. I talked to the instructor and he said it was a problem many of us experience, and wasn’t sure what was the exact cause or solution. Keep in mind this was an “official Business Objects training partner”.
It sounds like a pretty standard issue with the CMS.
I have a Win2003 Server using .NET Framework that connects to a remote Oracle 10gR2 database for its repository. The database goes down each morning at 3AM for a quick backup. I schedule the CMS to restart at 4AM each day. No matter what, whoever logs into InfoView first to InfoView and tries to view a report will receive the same error. Then they either go back, or refresh the page, click the report again, and it proceeds normally.
Tonight, I’m going to try to schedule a clean shutdown of the CMS just prior to the Oracle backup. I’m wondering if this error can be prevented by cleanly shutting down the CMS?
We had been seeing this sort of “random” behavior on mutilple installations. The reason I asked about the collation was we found that to be the issue. I’m not sure about Oracle though we are a MS SQL Server shop. SQL Server has collation settings at the Server as well as each individual database level, the Temp database automatically uses the collation of the server, so although the Temp DB’s collation was where we found the fix we had to change our server collations.
We found that the CMS’s SQL statements case syntax does not match the the case of the the actual temp tables it creates in some places. So that even if the CMS database’s collation itself is Case Insensitive, if the Server’s collation is Case Sensitive (and therefore the Temp database) you will begin to see “random” errors in the CMS. The CMS uses Temp tables for some of it’s statments. When it executes the statement it fails. I belive there is a re-try of 5 times before it errors. Then the CMS has a built in a limit of I think 3 errors before it just restarts itself. So for firms that had Case-Sensitive servers we would be in the CMC, adding a User, moving a Group, associating a value to a Profile all sorts of “random” administrative things and we would see errors here and there and then eventually the CMS would just re-start itself.
Example: This example would work on a Case-Insensitive Server, but would fail on a Case-Sensitive Server with a Case-Sensitive temp db.
CREATE TABLE #TMP_CAPS
(COUNTER INT, DESCRIPTION VARCHAR(15))
GO
SELECT Counter, Description FROM #TMP_CAPS
GO
DROP TABLE #TMP_CAPS
GO
I’m not 100% sure you are seeing the same issue, but it took us weeks to and multiple installations to figure it out. We eventually tracked the issues in the logs and were able to figure it out. But it was the cause of all sorts of problems. i.e. 20 users in a traning lab learning WebI designer. The trainer is configuring test values in the CMC. These temp errors evetually force CMS errors. 3 CMS Errors in the Event Viewer, and the CMS Server restarts iteslf. Suddenly 20 User’s WebI sessions are invalid and all their reports are failing. We’ve had clients ship BOE back because of this and at the time we had no idea why it was happening.
When using the host name (not the cluster name) on the CMC login screen, then the problem does not occur. How can I still be able to use the cluster name in the “System” textbox and be able to login successfully the 1st time after a CMS Service restart?
It seems BO provided (or will provide) a solution. After several tests and online sessions with the BO support it seemed that it is just like it is… Investigating the newest patches I found this entry: CHF17 ADAPT00668901 Patch ID: 39,587,370.
After asking BO about it, they investigated in their own patch and told me, that it seems the fix for our problem but they adviced me not to install CHF17 as there are issues with SP2 (funny to learn about this by investigating… makes me more careful installing patches in the future… ).
Now I’ve been adviced by BO support to install Fix Patch 2.2 to solve the problem. As good practice I went to the BO pages to find out more about Fix Patch 2.2 and found this:
BusinessObjects XI Release 2 - Service Pack 2 -Fix Pack 2.1Important Notice for customers using:
BusinessObjects BI Server and Business Objects Crystal Decisions
DO NOT INSTALL BusinessObjects XI R2 Fix Pack 2.1. Upgrading to SP2 will require Fix Pack 2.2 (available at the end of June 2007).
Once Fix Pack 2.2 is available, follow the steps below:
BusinessObjects BI Server Customers:
Install SP2
Then Install FP 2.2
Business Objects Crystal Decisions customers:
Install FP 2.2
OK, now I learned that the patch which BO advice me to install and test the next days is not availiable by now…
When the patch is coming out I will test it and keep you informed, if this is the solution…
According to the readme for Fixpack 2.1, ADAPT00668901 is included in Fixpack 2.1.
Please note that the disclaimer to NOT install Fixpack 2.1 is only meant for customers using BusinessObjects BI Server and Business Objects Crystal Decisions (these are the midmarket variants of XIR2). The 2.1 Fixpack is not compatible with these ‘stripped down’ versions.
If you have XIR2 Enterprise Pro or Premium, you can safely install Fixpack 2.1.
We recently began running into this issue with a standalone quad server running XI R2 SP1. We are a SQL Server 2005 SP1 shop. We began adding alot of users over the past 3 months and began to notice these mult sessions and slow CMS log in times. Has this temp table issue been attributed to any of your mult sessions/users executing several windows to run reports simultaneously.
As well as being logged into the system 8-10 times per user times 40 users?
Let me know if your temp table resolution helped to fix this, i’d be really interested.
I realise this topic is old now but I was searching for some answers and have discovered that specifying the port number :6500 in my case made everything work as without it the system uses the default 6400 port.
Not sure it that is of any benefit to anyone but it fixed my problems.
(BOB member since 2004-08-05)
(BOB member since 2007-03-28)
, but I doubt it as if there would be a problem with the clustername settings, the login shouldn’t work generally. I assume it has something to do with response time at the first login, as because of the logs the response time is longer which means the cluster got more time to answer… This is just a guess and I have no idea how to prove or test this.
(BOB member since 2006-05-11)
(BOB member since 2007-03-28)
(BOB member since 2006-12-09)
and told me, that it seems the fix for our problem but they adviced me not to install CHF17 as there are issues with SP2 (funny to learn about this by investigating… makes me more careful installing patches in the future… 
).
(BOB member since 2007-05-16)