Troubleshooting SRP Connectivity problems

Posted 09-24-2009 at 04:00 AM by hdawg

Tags srp test

---

Nope ... not going to reinvent the wheel here. KB10922 - Unable to establish an SRP connection because the SRP is disabled. Had to do some troubleshooting today and this is a good one that just got updated too! Just remember: TCP port 3101 only needs to be opened outbound, not inbound!

---

Overview

The Server Routing Protocol (SRP) is disconnected, and it remains disconnected even after restarting BlackBerry Enterprise Server services. To diagnose the issue, perform the following tests:

1. Check that port 3101 is available.
2. Run bbsrptest.exe from C:\Program Files\Research In Motion\BlackBerry Enterprise Server\Utilities. If there is an error in this utility, determine the point of failure.
3. Run telnet srp.na.blackberry.net 3101.

If these tests fail, the BlackBerry Enterprise Server will be unable to connect to the BlackBerry® Infrastructure. Troubleshoot, diagnose, and resolve any network-related issues. Once you have ruled out networking issues, test the state of the SRP by doing the following:

1. Go to Start > Program Files > BlackBerry Enterprise Server > BlackBerry Server Configuration.
2. Click the BlackBerry Server tab and validate the SRP ID and key.

If this test fails, the SRP might be disabled.

---

Additional Information

The SRP might be disabled for the following reasons:

1. Most SRP ID issues are caused by network issues. For example, the BlackBerry Enterprise Server can be disconnected because of a routing rule change, which stops all BlackBerry traffic.
2. Multiple BlackBerry Enterprise Server instances are connecting connecting concurrently with the same SRP ID. For example, a test or new BlackBerry Enterprise Server instance is implemented while the existing one is running.
3. It is a case of the 'five in one' rule. If the SRP connection is lost and five reconnection attempts are made within one minute, the SRP ID will be disabled. In addition to wireless network or firewall issues, this behavior can occur as a result of issues described in KB05368.
4. The BlackBerry Enterprise Server is using a trial or temporary SRP ID that has expired.
5. The BlackBerry Router is installed on a remote computer, and a communication problem exists between it and the BlackBerry Enterprise Server. If the BlackBerry Enterprise Server loses connection to the BlackBerry Router, the BlackBerry Dispatcher on the BlackBerry Enterprise Server will try to connect the SRP address itself. If the BlackBerry Router is still connecting to SRP, both the BlackBerry Router and the BlackBerry Dispatcher will connect using the same SRP ID simultaneously.
6. The BlackBerry Enterprise Server is connecting through a non-transparent proxy server to the Internet. The proxy server might create multiple connections to the SRP and cause the SRP ID to be disabled.
7. The network service between the BlackBerry Enterprise Server and the BlackBerry Infrastructure is interrupted. In this case, some data is still being transferred. For instance, the BlackBerry Enterprise Server tries to authenticate, and sends the SRP ID and authentication key to the BlackBerry Infrastructure. The request to authenticate is received, but the BlackBerry Enterprise Server does not receive a response from the BlackBerry Infrastructure, so it sends a new authentication attempt. If too many authentication attempts are sent within a short time period, the SRP becomes disabled.
8. Information is coming from a different host, and the BlackBerry Infrastructure terminates the original session and creates a new one. Also, some proxy servers may offer a round-robin feature for load balancing, where the source address of the proxy may change. If too many sessions are terminated and re-created within a short time period, the SRP ID may be disabled.

source: http://ow.ly/15QMZR

Configuring Exchange 2007 for Internet email

Update: Also check out this related post on dealing with certificate errors when users access Exchange from both the company's internal network as well as from the Internet:

http://thingsthatshouldbeeasy.blogspot.com/2009/02/certificate-errors-in-outlook-when.html

---

I had just installed and configured (at least I thought I did :) ) Exchange 2007. I sent a couple of test messages through from one internal account to another. Things seemed to be working well. But, when I tried to send a message to an external (Internet) address or receive a message, nothing happened. I did not get any obvious errors but the messages just did not get through.

It turns out that you must do some additional configuration on Exchange 2007 in order for it to allow inbound or outbound traffic from outside of its domain; that includes Internet messages. In order for Exchange 2007 to be able to send and receive Internet mail:

1. Enter the Internet FQDN as an accepted domain
   
2. Enter the Internet FQDN as an address policy ahead of the default policy for the local FQDN. This gives users two addresses: user@localFQDN and user@InternetFQDN and sets user@InternetFQDN as the default SMTP address. To test this, send an email from a user and check the user's from address. It should be user@InternetFQDN , not user@localFQDN. For example, if user jsmith in the mycompany.local domain sends the email, the from address should be jsmith@mycompany.com not jsmith@mycompany.local.
   
3. Allow anonymous permissions on the default Receive connector. This allows people from the Internet to send email to the Exchange organization. If this is not done, emails from outside bounce with a message saying the sender was not authenticated. To test this, send an email from an external account, like Hotmail, to a user within the Exchange organization.
   
4. Create a Send connector with the destination domain specified as "*". This allows the Exchange organization to send email to all domains. If this is not done, email sent outside the organization will be held by the server. The sending users will not receive any notice that their emails have not gone through. To test this, send an email to an external account, like Hotmail, from a user within the Exchange organization.

BlackBerry eMail Flow pada BES

1. e-Mail diterima Exchange Server

2. Exchange Server mengirim paket UDP ke BES server (dalam hal ini BES telah terinstall MAPI)
note: Paket UDP tidak mendapat jawaban ACK, jadi exchange tidak pernah tahu kalo UDP tsb diterima atau tidak.

3. BES server menerima paket dan menggunakan MAPI untuk mengakases mailbox sesuai dengan permission nya

4. Global Filter dan User Filter diperiksa untuk meyakinkan bahwa email tsb untuk BB

5. Jika iya, Pending count user akan meningkat di BES server.

6. Email di-enkripsi dan di-kompresi untuk selanjutnya dikirim melewati firewall pada port 3101 ke BlackBerry NOC
note: enkripsi menyimpan PIN user untuk tujuan routing.

7. Pending count user di BES berkurang, dan sebaliknya Sent count meningkat.

8. Email tersebut akan masuk ke Sent Item folder di exchange server (user pengirim)

9. email terbaca oleh NOC lalu di routing ke Operator tertentu sesuai dengan terakhir kali PIN tsb terdaftar.

10. Operator menerima email dan meneruskan ke BB

11. email diterima BB, lalu dilakukan proses dekompresi dan dekripsi.