[AirJunkie]

I have 4 BES's, 3 at one site and 1 at a remote site. They all talk back to a single SQL DB in the site where the 3 BES's are located.

I had to move some users from one BES to another (all in the primary site). Slightly less than 40% of the people that we moved stopped receiving messages to their blackberry. I went through the application logs and the agent logs and pulled out the following, where the last line states that the old BES is still handling the user that was moved off of it.

[30315] (08/26 18:04:34.679):{0x1BC8} {someguy@somedomain.com} Sending data to PIM Connector, size=354
[40279] (08/26 18:04:34.679):{0x1BC8} {someguy@somedomain.com} SubmitToRelaySendQ, Tag=2732587
[40793] (08/26 18:04:34.679):{0x1BC8} {someguy@somedomain.com} GetConfig request sent to the PIM Connector. Target=GetConfig
[30000] (08/26 18:04:37.913):{0x7C8} {someguy@somedomain.com} Sending data to Dispatcher, size=274, Tag=2732604
[40000] (08/26 18:04:37.913):{0x7C8} {someguy@somedomain.com} SendToDispatcher, Tag=2732604
[30384] (08/26 18:06:13.035):{0x1250} {someguy@somedomain.com} Packet has been delivered to PIM Connector, Tag=2732587
[20000] (08/26 18:06:28.832):{0x18F4} {someguy@somedomain.com} Switching services - failed.
[40845] (08/26 18:06:46.597):{0x1B78} {someguy@somedomain.com} SetPIMState - Registering for PIM synchronization (bState=1, bRet=1)
[30416] (08/26 18:06:46.597):{0x1B78} {someguy@somedomain.com} Established session with PIM Connector
[40799] (08/26 18:06:46.597):{0x1B78} {someguy@somedomain.com} Processed request from PIM Connector: cmd=0x5, Tag=4868004
[40279] (08/26 18:06:46.597):{0x1B78} {someguy@somedomain.com} SubmitToRelaySendQ, Tag=4868004
[30418] (08/26 18:06:58.315):{0x1A8C} {someguy@somedomain.com} Updated PIM config
[40799] (08/26 18:06:58.315):{0x1A8C} {someguy@somedomain.com} Processed request from PIM Connector: cmd=0x5, Tag=4868646
[40279] (08/26 18:06:58.315):{0x1A8C} {someguy@somedomain.com} SubmitToRelaySendQ, Tag=4868646
[40240] (08/26 18:16:35.594):{0x18D8} {someguy@somedomain.com} Handled by other server OldBBServerName

During this time period I also am seeing application logs that correspond to this user stating:

Event Type: Warning
Event Source: BlackBerry Messaging Agent NewBBServerName Agent 4
Event Category: None
Event ID: 20000
Date: 8/26/2008
Time: 6:06:28 PM
User: N/A
Computer: NewBBServerName
Description:
{someguy@somedomain.com} Switching services - failed.

It seems to me that although the user shows up under the NewBBServerName in BES Management, that there is still a field in the SQL DB that didn't get updated with the new servername (I'm open to other theories).

What I'm wondering is, why would a user move fail less than 40% of the time? Anyone have ideas for how to take that failure rate to < 10%?

AirJunkie

[ashworth]

hmmm maybe try restarting the dispatcher service (if you can) on both boxes. This can fix a lot of funky issues like this. it sounds like everything should have worked, maybe the agent just did not shutdown the user proper on the old box where the user was moved from???

[mahoward]

Do you have any logs from the POLC log file for the time during the user move? The switch services command is the piece where the handheld switches it's service books.

[qc_metal]

I agree - dispatcher service...

[AirJunkie]

Thanks for the posts, we did try restarting the services. What we determined to be the root cause for the high failure rate was the server that we moved the user's from was running the encryption algorythm 3DES and AES, where the servers that the user's were moved to was only running 3DES.

We are in the process of setting all our BES's to 3DES and AES encryption. Once we finish getting all systems to the same level of encryption we will be moving around a lot of user's to better load balance them. In theory having all 4 BES's at the same encryption level should reduce the failure rate to an acceptable level.

Best we've determined is that once the devices were talking using 3DES and AES, only some of them were able to downgrade the encryption to 3DES only. If I get time (hahaha), I want to inventory the devices and try to see if I can identify a common thread between the models that failed and the models that transitioned the encryption without issue.

Thanks again for the suggestions,
AirJunkie