Answered by:
Please clarify my understanding of OCS 2007 R2 Edge Servers

Question
-
We have a OCS 2007 R2 successful OCS 2007 R2 Standard single server/pool deployment for LM and Communicator. I've deployed a Consolidated Edge in our DMZ and it appears the connectivity/certs all work.
Where I am at now is basically confirming that this works but the problem I have is I don't have access to an external box where I can test this connectivity.
I hope this question doesn't sound too silly, but when I send a LiveMeeting Invitation to an external [anonymous] user they don't get a "webcon.eventzero.com" URL. They get the 'same' "Join this meeting" link.
Question 1: How does a LiveMeeting client know/determine the External URL? Is it based purely off the SIP address contained in the Email which is USER@domain.com?
Question 2: Is there such thing as being able to tell an external user, "go to http://webex.company.com, type in meeting ID and click join".
Our external DNS is seperated from internal AD/DNS, and we use named for this. So I was hoping on clarification for what records to create externally.Monday, August 3, 2009 8:03 AM
Answers
-
1. The Join Meeting link uses the Access Edge FQDN (typically sip.domain.com) when you should have published externally as a DNS A record. When the Live Meeting client connects to that FQDN the OCS server passes in-band the configured FQDN of the Web Conferencing Edge role (among other in-band configuration information). LM then attempts to resolve that FQDN as well,
2. No, a full meet:sip: meeting link must be provided.
You'll need to externally publish all three external Edge role FQDNs: Access Edge, Web Conferencing, and A/V Conferencing, as regardless of how the client receives the FQDN (SRV lookup, static link, in-band provisioning) it must still resolve that name to an IP address for communications.
Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS- Marked as answer by Matty_C Tuesday, August 4, 2009 7:01 AM
Monday, August 3, 2009 11:07 AMModerator
All replies
-
1. The Join Meeting link uses the Access Edge FQDN (typically sip.domain.com) when you should have published externally as a DNS A record. When the Live Meeting client connects to that FQDN the OCS server passes in-band the configured FQDN of the Web Conferencing Edge role (among other in-band configuration information). LM then attempts to resolve that FQDN as well,
2. No, a full meet:sip: meeting link must be provided.
You'll need to externally publish all three external Edge role FQDNs: Access Edge, Web Conferencing, and A/V Conferencing, as regardless of how the client receives the FQDN (SRV lookup, static link, in-band provisioning) it must still resolve that name to an IP address for communications.
Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS- Marked as answer by Matty_C Tuesday, August 4, 2009 7:01 AM
Monday, August 3, 2009 11:07 AMModerator -
Thank you for clarifying that, makes perfect sense.
So webcon, av and sip from an External DNS point of view just need DNS A records, and assuming the configuration for Edge to OCS are configured/running properly -- 'externally' the DNS A record is all that is required?
Can you please clarify is Public CA certs on the external Certs *NEED* to be publically CA signed. We have them signed from our internal CA and we understand they should be signed externally. But for finalization of our proof of concept we wouldnt mind saving $$$ in Verisign Certs until we prove it's online, in which we'll then 'switch' over to the Live CA certs.Tuesday, August 4, 2009 7:01 AM -
Yes, To support all external features you'll need external;;y published DNS A records for all three of those FQDNs. To support OC Automatic Sign-In you'll need an additional SRV record pointing to the Access Edge FQDN (both must be in the same domain namespace as the user's SIP address.
The most cost-effective solution is to use private certificates on the Edge Internal and A/V Auth roles with Public certs on the Access Edge and Web Conf roles. But for POC simply put internal private certs on all roles, and then buy public certs later and reassign them to the AE and WC roles.
Keep in mind that using private certs on the external roles will only work if the external clients trust the internal CA (happens by default with domain joined computers). Federation will only work if you give the federated partner your Root/Issuing certs as well. Public IM will NOT work without public certs.
See this article for more on setting up the certs and chain on the Edge server: http://technet.microsoft.com/en-us/library/dd441270(office.13).aspx
Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCSTuesday, August 4, 2009 12:18 PMModerator