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!
While most of us frequently deploy new ESXi hosts, a question and task not oftenly discussed is how to properly decommission a VMware ESXi host. Some might be surprised to… Read More
This guide will outline the instructions to Disable the VMware Horizon Session Bar. These instructions can be used to disable the Horizon Session Bar (also known as the Horizon Client… Read More
Normally, any VMs that are NVIDIA vGPU enabled have to be manually migrated with manual vMotion if a host is placed in to maintenance mode, to evacuate the host. While… Read More
You may experience GPU issues with the VMware Horizon Indirect Display Driver in your environment when using 3rd party applications which incorrectly utilize the incorrect display adapter. This results with… Read More
Today we're going to cover a powerful little NAS being used with VMware; the Synology DS923+ VMware vSphere Use case and Configuration. This little (but powerful) NAS is perfect for… Read More
Today we'll go over how to install the vSphere vCenter Root Certificate on your client system. Certificates are designed to verify the identity of the systems, software, and/or resources we… Read More
View Comments
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!