Sign in
Microsoft.com
 
Microsoft
 
 
 

locked
MOC works externally, but Live Meeting cannot successfully Test Connection RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote
    We have rolled out an OCS 2007 R2 Edge server, and I can log in fine with the Communicator client. Chat works, and I can initiate an audio call with Communicator, but once it tries to connect the audio call, it fails. Most importantly, though, chat works.

    Now, when I click the Meet Now button in outlook to create a new Live Meeting, it requires me to test my connection to OCS by clicking the Test Connection button. This is where it fails. I get the following message:

    Cannot connect to server because the information in the User Accounts dialog might be incorrect or improperly formatted. Please verify that this information is correct, and then click Test Connection. If you still can't connect, the server might not be available.

    I'm pretty sure it is due to the server being "unavailable," I'm just not quite sure why my Live Meeting client can't find the server. We have this working in our test environment, and I cannot think of any differences between production and test environments at this point.

    Here's what I've got set up so far:

    _sip._tls.<domain> SRV record pointing to sip.<domain> A record on port 443.
    sip.<domain> resolves to the Access Edge IP.
    webcon.<domain> resolves to the web conferencing edge IP.
    av.<domain> resolves to the A/V edge IP.

    I have confirmed that this SRV record in correct and these A records are in place and ping the correct IP's from the outside.

    We are not using a reverse proxy yet, but we are not doing this in the test environment either. I can just add that later.

    All the proper incoming ports are opened on those IPs:
    port 5061 and 443 TCP are opened on the Access Edge IP.
    port 443 TCP is opened on the Web Conference Edge IP.
    port 3478 UDP and 443 TCP are opened on the AV Edge IP.

    In the Global Properties, on the Edge Servers tab, I have added the internal FQDN of the edge server (and can ping that hostname from the front-end) to the Access Edge and Web Conferencing Edge Servers box, and the same internal FQDN using port 5062 is in the A/V Edge Servers box.

    In the Forest view of the snap-in, under Edge Server settings, I've got that same internal FQDN is under Access Edge Servers, and again under A/V Edge Servers over port 5062. And the pool name is referenced there as well. It shows <none> for the Mediation server, but i dont think that's important now (and it's the same in my test environment).

    In the Pool view of the snap-in, in teh Meeting Settings section, in the Web Conferencing Edge Server Settings area, I've got the internal port as 8057, external port as 443. The internal FQDN is the same internal FQDN, and the External FQDN is webcon.<domain>. In the A/V Conference Edge Server Settings, again I have the same internal FQDN and port 5062.



    These are about all the settings I can find pertaining to my Edge settings. Does anyone have any pointers on anything else I may have overlooked? If I need to look up any more info for anyone, please let me know.

    Thanks,
    Paul
    Wednesday, July 1, 2009 5:58 PM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote
    i ended up making a call to microsoft about this. Our DNS is a little wacky, and we had our sipinternaltls record published externally. We found a way to get it internal with a _tcp.<domain> subzone (we can't make a <domain> out of bounds zone or it will break a lot of stuff), and it works now. I think Live Meeting was using that record and failing, and then not trying the other _sip._tls.<domain> record.
    Thursday, July 9, 2009 12:18 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote
    Paul,

    See if this blog article helps, as it covers External Live Meeting access: http://blogs.pointbridge.com/Blogs/schertz_jeff/Pages/Post.aspx?_ID=67

    One gotcha is to make sure that the External Web Farm FQDN is populated with at least something, even if you don't have a reverse proxy rule published and setup.
    Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    Wednesday, July 1, 2009 6:29 PM
    Moderator
  • Question
    Sign in to vote
    0
    Sign in to vote
    I read through the blog post, and I believe everything is in place. Near the end of the article, you have, in green text, "Edge Server Properties > Access Method". Where is this Edge Server Properties thing? I've got remote access enabled for my user account, since I am able to connect with the Communicator client from the outside.

    Also, I do have an external farm FQDN set up. I used Matt Mcgille's suggestion here: http://social.microsoft.com/Forums/en-US/communicationsserversetup/thread/35b50691-2764-4d30-bb4a-783ce9f32c25/ . I setup this external fqdn after installing the pool.
    Wednesday, July 1, 2009 7:06 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    That's the Edge Server Properties on the Edge server itself.  Open up the Computer Management console and expand Services and Applications.  Then right-click on the objects for OCS Edge and select Properties.

    But it sounds like you have that enabled already since you've tested OC externally.  Can you telnet to port 443 on both the Access Edge and Web Conferencing Edge roles externally?  How many NICs and IPs are on your Edge server? 
    Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    Wednesday, July 1, 2009 7:32 PM
    Moderator
  • Question
    Sign in to vote
    0
    Sign in to vote
    oh wow, an actual snap-in for the Edge server? Microsoft really overlooked that in their admin tools installer.

    I just confirmed, I am able to telnet on 443 to both sip.<domain> and webcon.<domain>.

    I have 2 NIC's on my edge server. 1 NIC has the internal ip, and the other NIC has the 3 external IP's. This is the same way we did it in our test environment.
    Wednesday, July 1, 2009 7:42 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    So, now that I have a snap-in and can see a little bit more information, I see this in the Event log:

    Web Conferencing Server trying to connect is not enabled

    Over the past 30 minutes Web Conferencing Edge Server has rejected connection attempts from disabled Web Conferencing Server(s) 120 times. The last such connection attempt was from Web Conferencing Server which presented a certificate with subject name ocs.gtri.gatech.edu
    Cause: Web Conferencing Server trying to connect is not in internal server list
    Resolution:
    Verify Web Conferencing Server is configured in the internal server list


    Where is this "internal server list"? I thought I listed all my servers in one of the Edge setup wizard screens. Any thoughts?
    Wednesday, July 1, 2009 7:47 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    ok, i added my external farm fqdn to the list of internal servers that can connect to the edge server in the edge configuration. i am no longer getting that Web Conferencing Server error in the event log.

    here's a little tidbit for you, Jeff, that I hope might ring a bell in your brain about what I might need to do here. i connected one of my test computers back to the local network, and it threw the same error that i posted in my original post here. that confused me, but i finally realized i had been testing things with my hosts file. i was pointing ocs.gtri.gatech.edu (our external web farm fqdn) to my Access Edge IP address. When I removed that from my hosts file, it went back to using the local IP of our front-end and the Test Connection operation succeeded.

    So this whole operation is using the web farm fqdn somewhere. It seems like this could very well be a dns problem. DNS needs to point this operation to my Edge server, but then when the connection attempt reaches my edge server, maybe it also isn't doing something correctly.
    Thursday, July 2, 2009 2:07 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Interesting....it certainely sound like something isn't 100% right in DNS.  Just to clarify, the External Web Farm FQDN is not the Access Edge FQDN, but is the external DNS name that would be used to publish the internal Web Compnents via the Reverse Proxy.  So even if you don't have a Reverse Proxy deployed you should still have a DNS name selected for it (e.g. ab.domain.com) and it should nto be the same as the Access Edge external FQDN.

    Sounds like you have that part straight, just putting it out there for anyone reading as it's probably the most confused part of OCS.  I really don't like the name 'External Web Farm'.
    Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    Thursday, July 2, 2009 3:08 PM
    Moderator
  • Question
    Sign in to vote
    0
    Sign in to vote
    Yep, that makes sense. So how would simply taking that line out of my hosts file cause live meeting to then be able to successfully Test Connection? It's almost like Live Meeting is using that address for something. Is there a good write-up somewhere that explains the authentication process that Live Meeting goes through (i.e. what srv records/A records it uses and in what order)?
    Thursday, July 2, 2009 3:14 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    In fact, yes :)  This blog article covers the client connection process:
    http://blogs.pointbridge.com/Blogs/schertz_jeff/Pages/Post.aspx?_ID=14

    Office Communicator and Live Meeting both use the same process to login to the same Access Edge role.  The difference is that once Live Meeting connects it is passed the Web Conferencing FQDN in-band and then attempts to resolve that FQDN (via the published A record) to establish PSOM connectivity for meeting content.
    Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    Thursday, July 2, 2009 3:32 PM
    Moderator
  • Question
    Sign in to vote
    0
    Sign in to vote
    yes, that blog post helped me out tremendously last week  :-). thanks!

    as for MOC vs. LM, though...   If I'm getting passed into the Access Edge server successfully (as proven by MOC connecting successfully), then what further checks do I need to perform? My webcon.<domain> dns lookup succeeds and points to the proper IP address, and the inbound port 443 in opened up on the firewall. Also, we've got a cert on that interface, and it's assigned to the Web Conf. Edge interface.
    Thursday, July 2, 2009 3:45 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Take a look at the Live Meeting debug file at %temp%\pwconsole-debug.txt and see if there is anything in there that looks missing or incorrect.

    Also make sure your Time and Time Zone on the Edge server are correct.  We've seen that cause issues with only external Live Meeting connections were everything else worked.

    Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    Thursday, July 2, 2009 3:50 PM
    Moderator
  • Question
    Sign in to vote
    0
    Sign in to vote
    my pwconsole debug file doesn't seem to be very helpful. Where my local computer starts the connection and LiveMeeting configuration, the remote computer does have a few lines that say [X-JE] placeware::ConsoleConfApiB::isConfigured server: no

    also, my time zones are correct.
    Monday, July 6, 2009 1:34 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    i ended up making a call to microsoft about this. Our DNS is a little wacky, and we had our sipinternaltls record published externally. We found a way to get it internal with a _tcp.<domain> subzone (we can't make a <domain> out of bounds zone or it will break a lot of stuff), and it works now. I think Live Meeting was using that record and failing, and then not trying the other _sip._tls.<domain> record.
    Thursday, July 9, 2009 12:18 PM