Hi guys,
I come to you today to tell you a little story about a struggle I’ve been having with BES and users who are receiving the “Attachment Server not Found” error message on their handhelds.
For a few weeks now, a few users have reported issues with opening attachments, EVERYTHING else works perfect. I updated BES, checked everything, still couldn’t find out what was wrong. The only thing I had to go on, was a few very odd log entries inside of ASCL log file.
Example of entries in ASCL log:
[10000] (11/10 18:22:53.234):{0x21B0} [thr:0x21B0] CHALogic::_group_of_extensions_t::add_server_extensions(0) – no data
[10000] (11/10 18:22:53.236):{0x21B0} [thr:0x21B0] CHALogic::_list_of_servers_t::Add(0,…) – no need to add empty STRINGS_SET
[10000] (11/10 18:22:53.236):{0x21B0} [thr:0x21B0] CHALogic::_group_of_servers_t::AddServer(0,…) – _preferred.Add() failed with rc=1007
[10000] (11/10 18:22:53.244):{0x22AC} [thr:0x22AC] CArznDelayedAttachmentResultVisitor::Uninitialize() – begin
[10000] (11/10 18:22:53.245):{0x22AC} [thr:0x22AC] CArznSocket::Close() – m_connectSocket = 0xFFFFFFFF, after
[10000] (11/10 18:22:53.245):{0x22AC} [thr:0x22AC] CArznDelayedAttachmentResultVisitor::Uninitialize() – end
[10000] (11/10 18:22:53.245):{0x22BC} [thr:0x22BC] CArznSocket::Close() – m_connectSocket = 0xFFFFFFFF, after
[10000] (11/10 18:22:53.248):{0x22C8} [thr:0x22C8] CArznDelayedAttachmentResultVisitor::Uninitialize() – begin
[10000] (11/10 18:22:53.248):{0x22C8} [thr:0x22C8] CArznSocket::Close() – m_connectSocket = 0xFFFFFFFF, after
I spent a few days googling the error “Attachment Server not found”, and came across numerous KB articles that wanted us to try this, try that, bla bla. Everything was configured properly, and the service was running. So all of these did not apply to me!
Finally I took a LONG hard stare at the errors in the ASCL log shown above, and put 2 and 2 together and realized it probably had something to do with TCP/IP communication. I finally STOPPED the attachment service, opened a command prompt and issued:
netstat -ano |find /i “Listening”
Even though the Attachment server runs on 1900, 1999, and 2000 (I could be wrong if it’s those specific ones), but even after stopping the service I noticed that there was still something listening on 2000. I used the PID issued by the -o switch on netstat, opened task manager, showed all tasks from all users, and changed the view settings to show the PID column.
BAM! Turns out some other piece of software was listening on 2000. Go Figure!
To Resolve this:
1) Log on to the BlackBerry Administrative Web Site
2) Under “Servers and components”, except the Solution topology, expand Domain, Server View, Server_Name, and select “Server_Name_AS_11”
3) Select “Edit Instance”, and then proceed to change the port (in my case, 2000 was conflicting, so I changed 2000, to 2001).
4) Restart the server!
You’re now good to go!
Thank for posting this. I tried a ton of other “suggestions” from other blogs and the BB support site and forums to no avail. Found this article and BAM! it all comes together. In my case it was, again, port 2000 with DesktopAuthority using that port.
Np 🙂
Glad it helped someone else!
Dude…after DAYS of searching this completely saved my ass. On one hand I’d love to beat up on Blackberry for not having better logs but it was a search string from my own set of logs that led me here. Well done and thank you!
When I was experiencing this, I was surprised that there was absolutely nothing on the internet that helped with this. In my case, it was N-Able’s “N-Central” monitoring software that was causing the conflict with the BES attachment server. I use the software to monitor my client’s environments.
Thank you
In our case it was a piece of n-able software as well, their desktop agent ‘RemoteSupportManager’ with a file name of DesktopAuthority.exe
Your tip helped a lot
Excellent work! this got me out of a fix as well, after reading through numerous posts from RIM which didnt help this sorted it, thanks again
Thank you. I wasted half a day on this.
Well Heather,
I’m glad it was just a half day for you. It took a whole week of my time to figure it out! haha
I wish I could buy you a beer mate! Worked like champ! Thanks heaps
Worked for me as well. Although the netstat switch failed for me on Windows 2008. So just used netstat -ao > C:\port.txt to sent to a text file. -ao gave the port and puid and it came down to RMSWinService.exe hogging the BES Result Port on 2000. This app was unknown and so was disabled. The BES port was changed in any case. Turns out RMSWebService/RMSWinService is an N-Able Technologies solution, we suspect this dynamically was binding to 2000 when possible or in idle state as Attachments worked intermittently.
This article helped me to prevent 10 error messages per second in the application event log.
Thanx!