locked
Edge server setup RRS feed

  • Question

  • Hello,

    I have two network cards. One is internal and one is on DMZ.  DMZ card is connected to the firewall.

    Internal card is setup without default gateway, and has internal DNS servers.

    DMZ card has default gateway and public DNS servers (8.8.8.8 and 8.8.4.4).

    Our domain names are doman.internal and domain.net. Sip domains are domain.internal and domain.net. Internal DNS server had domain.internal and domain.net zones.  Also, we have domain.net external DNS server.

    Hosts file on the Edge server has IP addresses to lyncsrv1.domain.internal, lyncsrv2.domain.internal, edgesrv.domain.internal, tmg.domain.internal, dc1.domain.internal, pool.domain.internal, and pool.domain.net.

    From Edge server I cannot ping sip.domain.net, webconf.domain.net, av.domain.net.

    At this time we have a problem with audio/video and conferencing.  Can it be because the edge server cannot resolve those names?  Should it be able to find them?  Should it be public, DMZ, or LAN addresses?  What addresses should be in the hosts file? Where should they point (public, DMZ, or LAN addresses)?

    Anyone knows?

    Thank you.


    Thank you. Eric.

    Tuesday, August 28, 2012 4:04 AM

Answers

  • 1. To avoid some issues later, make sure domain.net is your Default SIP Domain. This is not relevant to your issue, but rather best practice.

    2. The HOSTS file of the Edge should have lyncsrv1.domain.internal, lyncsrv2.domain.internal, and pool.domain.internal. Domain.net records are not necessary.

    3. Make sure .net DNS zone have the correct A records with IP addresses - the public IPs mapped to DMZ IPs.

    4. Make sure in Topology, Edge node, NAT you specify the Public IP address of the AV edge. This is the most common mistake.

    5. Verify the correct Firewall ports are open.

    6. Visit https://www.testocsconnectivity.com and run "Microsoft Lync Server Remote Connectivity Test with AutoDiscover" where "Perform Audio/Video Server Connectivity Test" is checked.

    Let us know the output of the above test.

    .

    Drago


    http://www.lynclog.com

    • Proposed as answer by Kent-Huang Thursday, August 30, 2012 7:23 AM
    • Marked as answer by KPABA Thursday, August 30, 2012 2:02 PM
    Tuesday, August 28, 2012 1:36 PM
  • Hi,

    1. You need to edit the host file on edge server to contain record for the next hop server. The record helps Edge server to resolve internal front end pool that was configured as the Edge Server next hop address in Topology Builder. Thus,  it don’t need to include domain.net records.

    2. The Edge should be able to resolve sip.domain.net, webconf.domain.net, av.domain.net. It should be DMZ addresses.

    3. The Edge troubleshooting tips for your reference:

    http://blogs.technet.com/b/nexthop/archive/2011/12/07/useful-tips-for-testing-your-lync-edge-server.aspx


    Regards, Kent Huang

    TechNet Community Support ************************************************************************************************************************ Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question.




    • Edited by Kent-Huang Wednesday, August 29, 2012 9:24 AM
    • Proposed as answer by Kent-Huang Thursday, August 30, 2012 7:23 AM
    • Marked as answer by KPABA Thursday, August 30, 2012 2:02 PM
    Wednesday, August 29, 2012 9:22 AM

All replies

  • 1. To avoid some issues later, make sure domain.net is your Default SIP Domain. This is not relevant to your issue, but rather best practice.

    2. The HOSTS file of the Edge should have lyncsrv1.domain.internal, lyncsrv2.domain.internal, and pool.domain.internal. Domain.net records are not necessary.

    3. Make sure .net DNS zone have the correct A records with IP addresses - the public IPs mapped to DMZ IPs.

    4. Make sure in Topology, Edge node, NAT you specify the Public IP address of the AV edge. This is the most common mistake.

    5. Verify the correct Firewall ports are open.

    6. Visit https://www.testocsconnectivity.com and run "Microsoft Lync Server Remote Connectivity Test with AutoDiscover" where "Perform Audio/Video Server Connectivity Test" is checked.

    Let us know the output of the above test.

    .

    Drago


    http://www.lynclog.com

    • Proposed as answer by Kent-Huang Thursday, August 30, 2012 7:23 AM
    • Marked as answer by KPABA Thursday, August 30, 2012 2:02 PM
    Tuesday, August 28, 2012 1:36 PM
  • Drago, thank you for your reply.

    I understand that hosts file should not have any of those records, but it cannot resolve any of domain.net addresses.  Is this a problem?  Checking the Snooper on the edge server, there are no errors, but I see Data: destination="Unknown" in some places and it worries me.

    When you say to make sure that .net DNS zone points to the public UPs mapped to DMZ IPs, do you mean external?  Or internal?  If internal, why would it point to public IP addresses.  I do not want to argue, just making sure.

    Right now in Topology, Edge node points to the SIP Access IP address.  I will change it to the A/V and let you know if it helped.

    Correct firewall ports are opened.  I checked it about 10 times by now.

    When I run test connectivity test with autodiscover, it gives me the following error:

    Testing SSLCertificate for validity.
    The SSLCertificate failed one or more certificate

    Additional Details
    If you are using a Reverse Proxy to get to the Access Edge Server, this could possibly be an issue with Reverse Proxy configuration.: Exception Details: Message: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.

    The problem with this test is, I do not have public SRV records.  Cannot create them, but it should not be a problem.

    When I run the test without Autodiscover, I have the same error if I specify port 5061.  The test is successfull if I specify port 443.

    Any ideas?

    Thank you.


    Thank you. Eric.

    Tuesday, August 28, 2012 2:06 PM
  • domain.net is your public domain. In this regard, traffic from public internet should "worry"about .net, not internal servers.

    In the above context, if your DMZ IP assigned to the edge interface is 192.168.0.5 which is mapped to public IP x.x.x.5, the public facing DNS A record should point to x.x.x.5, because this is what my Edge will use to federate with your edge.

    It is obvious you have certificate issue. Try to run the test again, but this time check "Ignore Trust for SSL" box. This will allow the test to drill down deeper. We will revisit the certificate issue later.

    By the way, what is you public domain? You will expose it fia federation records later, so having it posted here is not a big deal :-)

    .

    Drago


    http://www.lynclog.com

    Tuesday, August 28, 2012 2:41 PM
  • Sorry, I cannot post domain here.  This is for the client and they are very high on security.  This is one of the reasons they would not have SRV records.  No federation now or in a future. I can let you know personally, but cannot post it here.

    When I run the same test and check ignore SSL, I have exactly the same result.  Port 5061 only.

    I understand that public DNS records should point to the public IP addresses.  But we also have internal domain.net zone.  Should I create those records on internal domain.net DNS zone?  Because we have internal domain.net DNS zone, we cannot resolve those public IP addresses internally.

    Our domain.internal DNS is setup correctly.  i worry only about internal domain.net zone.

    Thank you.


    Thank you. Eric.

    Tuesday, August 28, 2012 3:14 PM
  • I understand your concern!

    I am willing to help. Cases like this are learning curve for me too :-)Email me if you want - temp2 @ lynclog.com

    .

    Drago


    http://www.lynclog.com

    Tuesday, August 28, 2012 3:45 PM
  • Thank you very much.

    I emailed you the domain name.  Please let me know if there is any other information you need from me.

    Thank you.


    Thank you. Eric.

    Tuesday, August 28, 2012 3:48 PM
  • KPABA

    Just throwing this out there ...  If your unable to resolve and ping by direct IP address.  I would look into which side (external or internal) you have your gateway set.  This has caused issues in the past.

    -Steve

    Tuesday, August 28, 2012 4:06 PM
  • Thank you for your input.

    I am unable to resolve sip.domain.net, etc only when I am on the Edge server.  This what I wanted to know, do I need to add something in the hosts file?

    Thank you.


    Thank you. Eric.

    Tuesday, August 28, 2012 4:09 PM
  • Eric:

    Just trying to clarify the setup.  Are you using multiple IP addresses for the different roles are using the same IP on different ports?

    I would double check to make sure that the edge server itself is listen on the IP/ports that you have assigned for the different roles.

    The clients (internal or external?) that are trying to connect to the different roles need to be able to resolve the roles? 

    I going on the assumption that IM and the rest of the functionality works except conferencing and A/V.

    I'm doing some testing to see if the edge server itself actually needs to resolve the sip domain space.

    Tuesday, August 28, 2012 4:35 PM
  • Steve,

    I am using multiple IP addresses for different roles on teh edge.

    I double checked and Edge server listens correctly.

    IM is working.  As far as I can see, the problem is audio/video.

    Actually new interesting fact.  I was using Atendant from my home VM to connect to the meeting.  I did not have Audio installed but I was able to connect, I was able to share whiteboard and poll, but not the desktop.

    I installed virtual audio driver and now I cannot connect to the meeting.  It connects, kicks me out and gives me an option to rejoin the meeting.

    If I disable this virtual audio device and restart my VM, I can connect to the meeting if I select that I will call in seperately.

    Interesting..... But not sure what to do.

    Any ideas?

    Thank you.


    Thank you. Eric.

    Tuesday, August 28, 2012 5:55 PM
  • Hi,

    1. You need to edit the host file on edge server to contain record for the next hop server. The record helps Edge server to resolve internal front end pool that was configured as the Edge Server next hop address in Topology Builder. Thus,  it don’t need to include domain.net records.

    2. The Edge should be able to resolve sip.domain.net, webconf.domain.net, av.domain.net. It should be DMZ addresses.

    3. The Edge troubleshooting tips for your reference:

    http://blogs.technet.com/b/nexthop/archive/2011/12/07/useful-tips-for-testing-your-lync-edge-server.aspx


    Regards, Kent Huang

    TechNet Community Support ************************************************************************************************************************ Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question.




    • Edited by Kent-Huang Wednesday, August 29, 2012 9:24 AM
    • Proposed as answer by Kent-Huang Thursday, August 30, 2012 7:23 AM
    • Marked as answer by KPABA Thursday, August 30, 2012 2:02 PM
    Wednesday, August 29, 2012 9:22 AM
  • I found my problem.  Stupid mistake.  Typo in Topology Builder, wrong public IP address.


    Thank you. Eric.

    Thursday, August 30, 2012 3:14 AM