[hugheser]

Not yet unfortunately. I replied to the incident again today asking if they can give me any more info. They haven't sent me anything new in several days now. I will update here once I know more. In the meantime, I've been cleaning out several gigs of logs a day and I still can't use the BESUserAdminClient to get user lists or status info.

[jah8903]

ok, thanks. I can't believe they have not come up with a fix as yet knowing that so many people are having this issue.

[jah8903]

Since you still have not heard back from Blackberry your best bet would be to revert back to the old db ver. 5.0.0. It should have created a backup of the SQL db prior to you upgrading.
I uninstalled all BB software, backup the current SQL db and remove it from SQL and restore the db from ver. 5.0.0 and then install the software ver 5.0.0. You can also install all the MRs just not SP1 and you should be good.

[besadmin23]

Was RIM able to get to the bottom of this one for you?

[knip]

Was having a similar issue to this one. Called RIM via CDW support and got to the bottom of it. This may or may not work for you but is worth a try.

Our issue had to do with Administration Service KeyStore password.

1. Stop all BES Services
2. Goto regedit (make backup copy..)
3. hk_current_user\software\RIM\BES\Administration Service\Keystore
4. Delete CACertskeystorepass (not the data, the whole string)
5. Restart services....or just restart the server...
6. Try to hit your Admin Web Service.

Wait. Wait. I think 10 Min went by before I was able to login.
You can check the BAS-AS process. It should be using quite a bit of memory.

Hope this helps someone.

[JavaJunkee]

Was this ever resolved?

It seems the issue was port 443 was not listening. This is my current case.

I was struggling with a another issue regarding Web Desktop Mgr and had completely uninstalled BAS from all my servers. Upon re-installing, port 443 is closed.

I've installed BAS on a new server (as a test), and it works just fine, port 443 is listening.

[JavaJunkee]

Well . . . (not meaning to hijack your thread)

Here was my error from BBAS-AS on the two affected servers:

(02/09 14:56:46:254):{main} [org.apache.coyote.http11.Http11Protocol] [INFO] Initializing Coyote HTTP/1.1 on http-<server>%2F<IP Address>-18180
(02/09 14:56:46:269):{main} [org.apache.coyote.http11.Http11Protocol] [ERROR] Error initializing endpoint
java.io.IOException: Keystore was tampered with, or password was incorrect

I resolved my issue as follows:

Since port 443 was listening on my newly installed BAS (test server), I copied the web.keystore file located at C:\Program Files (x86)\Research In Motion\BlackBerry Enterprise Server\BAS\bin\, to my two pilot servers. After a reboot, port 443 is now listening and I am once again able to setup BAS round robin DNS to those two machines.

I choose this rather then using webGenKey.bat to regenerate the web.keystore file. WOOT!

[trancemaasta]

Originally Posted by mahoward

You cannot have BAS installed on the primary and secondary nodes of a cluster. I learned this the hard way as there is no documentation stating this. One instance claims status as the master and therefore the other instance cannot start.

I'm afraid you are going to be stuck with only 2 BAS instances in your failover topology instead of the expected 4 unless you build some more servers.

Here is my ticket resolution from RIM:

Hello,

Your Service Request has been logged and the following course of action has been
provided in response to your inquiry. If you have any questions concerning this request,
please reply to this email within the next three (3) business days.

Details:
TX3 BES 5.0 MR2 Exchange 2003 SP2 SQL 2005 Unable to login to BAS

Resolution:
Stopped BAS services on fail over BES

The resolution that was provide was for you to be able to manage your BES, not for you being able to manage your BES aswell as have more than two BAS' in your environment.

I would imagine that because this allowed you to manage the rep sensed that you were happy about this and decided to not fix the root cause of the issue.

Just an FYI in regards to any kind of support.

And.... The BAS can and will work on every BES that you have in your environment whether it be Primary,Secndary,Tertiary or Standby etc....

[Kris Adolfsen]

Hi Everyone,
I came across this problem today after a reboot. I'm running BES 5.01 and no changes have been made but this issue started happening out of the blue. So the error I am getting is:

(04/27 13:27:21:773):{main} [org.apache.coyote.http11.Http11Protocol] [INFO] Initializing Coyote HTTP/1.1 on http-SERVER_DNS_ALIAS%2F10.192.1.225-18180
(04/27 13:27:21:820):{main} [org.apache.coyote.http11.Http11Protocol] [ERROR] Error initializing endpoint
java.net.BindException: Address already in use: JVM_Bind:443

I looked thru this article and didn't get very far but knew to look at port 443. At the same time I opened a ticket with RIM. After talking to a tech who only knew how to read queue cards we found a workaround article RIM had on the error above. The key to this was Address already in use: JVM_Bind:443".

The tech had me stop the BAS application service and change the port used by HTTPS to 663 instead of 443. When I restarted the service and change the BAS URL to include :663 in the webaddress it started working. He checked with an upper level tech on the root cause and came back with it being a firewall issue. Well that wasn't a good answer in my case. So after getting off the phone with the tech I ran some more tests. The test that resulted in the most clues was netstat

C:\>netstat -an | findstr 443
TCP 0.0.0.0:443 0.0.0.0:0 LISTENING


This indicated to me that 443 isn't listening properly.

So next thing I do is check to see if IIS was holding port 443 and sure enough it was. I disabled the IIS server and set back BAS to 443 and then started the service again.
This time the netstat returned

C:\>netstat -an | findstr 443
TCP 10.192.x.x:443 0.0.0.0:0 LISTENING

Tested the BAS console and it works. Hope this helps.