I have also confirmed the internal clients can resolve the FQDN of the Edge Server Internal address from all subnets.
The Edge server does resolve to the correct public IP Address when running a query to the "av.au".
We are using a Cisco ASA device to provide the DNAT in, and SNAT out for the A/V Edge Server to the public IP Address. The option on the Edge Server A/V component, "External IP Address is translated by NAT" has been enabled. In reply to your questions listed above: We are using the NAT option on the OCS 2007 R2 Edge Server (consolidated Edge Server). Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS Next thing to check is that internal clients (on all internal subnets/sites) can both resolve the Edge Internal FQDN correctly as well as connect to that IP over both 4, which are required for internal clients to communicate to external clients for A/V and Desktop Sharing. Regards Danįirst off Live Meeting and Office Communicator use different ports for 'desktop sharing' as the OC client negotiates Desktop Sharing connections over media ports (it's basically RDP over RTP) while Live Meeting performs application sharing over just a few ports (4 internally, 443 only for external clients).įirst things to check are (1) if you are using NAT on the A/V edge roles are you using a supported firewall and have you configured the NAT setting in the A/V Edge Properties as well as setup an internal (or perimeter) DNS record (or HOSTS file entry on the Edge server) for the av. FQDN pointing to the public IP assigned to A/V? If not using NAT then theses steps don't apply. I am going to keep my fingers crossed for the moment. Un-fortunately I am not sure which certificate actually fixed the issue or if it was the new Server 2008 (SP2) internal Certificate Server which fixed it. After this everything tested, OK (still waiting on more external users to test before celebrating though). I requested new certificates for the internal interface of the Access Edge server (internal Root CA Certificate), the A/V Authentication server (internal Root CA Certificate) and the internal interface of the Front-end server. I also deleted the OCS 2007 R2 Std Edition Standard Edition internal Front-End server certificate. I then deleted the internal (perimeter) certificate and the A/V authentication certificate from the OCS 2007 R2 Std Edition Consolidated Edge server. Hi, I have had my suspicions regarding the internal certificates being the issue (even though OCS BPA, Validation, Logging and Event Viewer did not report any errors).Īnyway as an experiment I configured a new Server 2008 (SP2) server on the internal network as a new internal Root CA (previously running on Server 2003). If anyone has seen issues similar to this, any assistance or suggestions would be appreciated. Why are the Live Meeting client sessions for A/V and Desktop Sharing always successful? When the Communicator A/V and desktop Sharing sessions fail to external clients? Is there any way to trace the Communicator client sessions to see why it is breaking for external clients? I have also confirmed the Public (Go-Daddy) Certificates on the Edge server are correct. I have tripple checked the OCS 2007 R2 Edge server configuration and firewall rules, all appears to be fine. When trying to establish a Communicator Desktop Sharing or A/V session with an external (internet) user it displays "Connecting" then simply fails to connect. When on the internal network I can establish Communicator Desktop Sharing and A/V connections with other internal Communicator users (including users in WAN connected subnets). The Live Meeting 2007 A/V and Desktop Sharing always works fine. This is only an issue with communication to external Communicator users and Federated users. I am having an issue with Office Communicator 2007 R2 clients initiating a Desktop Sharing and also A/V calls.