Wednesday, September 29, 2010

OCS 2007 R2: “Some calls to and from people outside of your corporate network may not connect due to server connectivity problems… ” message is intermittently displayed to MOC users but calls continue to work

We had a client out West who have been undergoing network infrastructure changes and after completing the majority of the project, they began to notice that an error message intermittently gets displayed for users when they use MOC to call other remote users connected through the Edge server. The error message reads:

Some calls to and from people outside of your corporate network may not connect due to server connectivity problems. Try signing out and signing back in. If this problem continues, contact your system administrator with this information.

clip_image002

Since this appears to only affect calls from the internal network going out through the Edge server, I went straight to the front-end server and ran the following validation tests:

Front-End Server Validation:

image

Web Conferencing Server Validation:

image

A/V Conferencing Server Validation:

image

To eliminate a connectivity issue, I did a simple telnet from the front-end server to the edge server via the port 5062 and the connection establishes. I also checked the static persistent routes on the edge server to ensure the appropriate routes for the 172.x and 10.x subnets are in there.

clip_image002[6]

All of these errors point to a mismatch of what the front-end server anticipates and what is presented. In this client’s case, it’s because the internal interface on the Edge server is currently using the public certificate with the name sip.companyName.com. When the internal front-end server initiates a connection over to the Edge server, it uses the name “xxx-edge-01.someDomain.local”.

image

To confirm that the edge server is indeed presenting the wrong interface, we can look at what certificate is assigned as shown here in the properties:

image

I went ahead and double checked the sip.companyName.com certificates and none of them have a SAN entry for the internal name. This means that they should use an internally issued certificate with the proper internal edge server name for the internal interface. The screenshot above shows that there’s actually such a certificate but it’s not assigned.

Resolution

The resolution is simple: all we need to do is assign the internal certificate. I’ve verified the expiry date for the certificate and it hasn’t expired yet.

image

image

Once I changed the certificate, the error in the validation went away and users stopped receiving the error message.

2 comments:

Anonymous said...

Nice article and right on the money. Fixed my exact problem...thanks.

Erick Brooks said...

Something is really wrong with the setup when the usual bug fixes aren't working. Hopefully, your post here would make the users be more understanding about how technical internal networking is, and that the resolution for each glitches are not as easy as it seems. Thanks for sharing!

Erick Brooks @ Ripple Web