Office Communicator 2007 R2 Client Desktop Sharing with external users and Federated Partners not working.
15 ตุลาคม 2552 9:56I am having an issue with Office Communicator 2007 R2 clients initiating a Desktop Sharing and also A/V calls. This is only an issue with communication to external Communicator users and Federated users. The Live Meeting 2007 A/V and Desktop Sharing always works fine.
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). 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. I have tripple checked the OCS 2007 R2 Edge server configuration and firewall rules, all appears to be fine. I have also confirmed the Public (Go-Daddy) Certificates on the Edge server are correct.
Is there any way to trace the Communicator client sessions to see why it is breaking for external clients?
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?
If anyone has seen issues similar to this, any assistance or suggestions would be appreciated.
- เปลี่ยนแปลงประเภท Gavin-ZhangModerator 22 ตุลาคม 2552 3:09
15 ตุลาคม 2552 13:41ผู้ดูแลFirst 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 (443 and 8057 internally, 443 only for external clients).
First 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.domain.com FQDN pointing to the public IP assigned to A/V? If not using NAT then theses steps don't apply.
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 443 and 3478, which are required for internal clients to communicate to external clients for A/V and Desktop Sharing.
Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS
- เสนอเป็นคำตอบโดย Gavin-ZhangModerator 22 ตุลาคม 2552 3:19
22 ตุลาคม 2552 3:20ผู้ดูแล
Any update for your issue?
Jeff gave a good suggestion.
22 ตุลาคม 2552 10:44
Thanks for the reply Jeff. In reply to your questions listed above:
We are using the NAT option on the OCS 2007 R2 Edge Server (consolidated Edge Server). The option on the Edge Server A/V component, "External IP Address is translated by NAT" has been enabled. 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 Edge server does resolve to the correct public IP Address when running a query to the "av.our.public.domain.com.au".
I have also confirmed the internal clients can resolve the FQDN of the Edge Server Internal address from all subnets. Also the internal clients can connect to the required ports (443 and 3478 UDP) to the internal IP Address of the Edge Server.
A couple of other questions regarding the Consolidated Edge Server configuration. The server has two physical interfaces, one is dedicated to the internal interface and can communicate to the internal network from the perimeter network. The other nic is configured with three IP Addresses for Access Edge, Web Conf Edge and AV Edge roles. Should I be using 4 x physical network cards?
Is there a best practice for running a logging / trace session for the RDP over RTP communications? I have been working with the OCSLogging Tool without much luck?
Thanks in advance,
26 ตุลาคม 2552 5:02
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).
Anyway 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).
I then deleted the internal (perimeter) certificate and the A/V authentication certificate from the OCS 2007 R2 Std Edition Consolidated Edge server. I also deleted the OCS 2007 R2 Std Edition Standard Edition internal Front-End server certificate. 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. After this everything tested, OK (still waiting on more external users to test before celebrating though).
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. I am going to keep my fingers crossed for the moment.
- ทำเครื่องหมายเป็นคำตอบโดย Dan Funk IT 26 ตุลาคม 2552 5:02