Wednesday, July 20, 2011

Configuring Lync for External Access

Out of all the posts I've made on this blog, the one post that gets the most page hits and has generated the most comments is my post on Lync External Web Services without Reverse Proxy. Obviously, there are a large number of users that don't want to deal with putting in a reverse proxy solution such as ISA or TMG.

I always recommend that companies do use a reverse proxy instead of going direct to the front-end, simply because its more secure.  Opening up any domain-joined server to the Internet directly is risky, but as long as the company understands the risks, I will configure Lync to work without a reverse proxy.

The majority of comments on my aforementioned post are questions around which DNS names point to what, and what ports to open to where.  This post will attempt to clarify how to configure Lync for external connectivity by using a simple example with a single Standard Edition Lync front-end and a single Lync edge server.  This is the minimum number of servers required to provide all Lync functionality, and is the most likely configuration for a lot of small companies with limited resources.

The Lync team has done an admirable job of simplifying what has typically been a complicated install process.  The Topology Builder and the Deployment Wizard make it so that complex Lync installations can be done with relative ease.  However, I have found that administrators get confused fairly early in the deployment process and if things aren't done right, problems will arise later.

Web Services URL
Imagine a small company called Contoso (yes, original, I know).  Their external web presence uses contoso.com and their internal Active Directory domain name is contoso.local.  They are in the initial stages of their Lync deployment and are using the Topology Builder to configure their deployment.  As with a lot of administrators, rather than spending days reading the reams of documents around Lync, they have decided to dive right in.  Things go well using the Topology wizard, and most things are clearly explained and the admin can click Next with confidence.  They set the SIP domain to contoso.com and the front-end server name to FE.contoso.local

However, once they get to the Specify the Web Services URL screen, things will be set incorrectly if they accept the default and click Next.

The Web Services URL is a hidden URL used to direct Lync clients to the proper place to download address book files, meeting content and other things.  This connection is done via HTTPS.  Internally, the client uses the internal FQDN of the server (FE.contoso.local), but externally, they will need to use a publicly accessible URL.  Since contoso.local is not a publicly accessible domain, they should use contoso.com.  It doesn't really matter what the URL is (clients never see this), but I will use LyncWeb.contoso.com in this example.  For deployments with multiple front-ends and/or directors, I would use something a bit more descriptive like LyncFE1.contoso.com.

Edge Configuration
Now, with that set properly, the administrator can continue on to the edge configuration.  The FQDN of the edge pool should be something like Edge.contoso.local, but it could really be anything.  The next critical thing is the external FQDNs.  Again, since clients need to be able to access this URLs externally, it must be a publicly available URL.  With the edge, you can either use a single URL or 3 separate ones for the Access, Web Conferencing and A/V URLs.  I recommend using 3 separate URLs if you have the available external IP addresses.  If you elect to use a single URL, you may have A/V issues  with companies that still use OCS.  In this imaginary case, we used SIP, WC and AV (all contoso.com).

If you are NATting your edge server (and you selected The external IP address of this Edge pool is translated by NAT on the Select Features page), you will be presented with a page that will likely make you pause and wonder:

If you are using only a single IP for SIP/Web/AV, then it should be pretty straightforward what to put here.  You would put the public IP address that external users will connect to.

If you are using separate IPs for each service, then you need to type the public IP address of the A/V service.  Lync needs this information so A/V services will work reliably across the NATted interface.  I'm hoping Microsoft will make this dialog box more informative in a future release. 

Meet/Dialin URLs
Once you enter the required IP addresses and finish the wizard, you should have all that is required to install Lync on your servers.  At the main Topology Builder screen, you will notice the Simple URLs have been automatically set to https://meet.contoso.com and https://dialin.contoso.com.  These URLs are used by clients to join meetings, view dial-in access numbers and change their PINs. You can accept this default, or if you are trying to minimize costs, you can change the URLs to something else like https://Lync.contoso.com/meet and https://Lync.contoso.com/dialin.  This way, you can get a cheaper certificate without a SAN.


External Network Configuration
For all this to work, you will have to make several firewall rules and DNS entries.  Since a picture is worth a thousand words, I figure I'd summarize it with this snazzy Visio I made for a design doc for a client (click on it for a larger view).

The main points to notice is that both Lync.contoso.com and LyncWeb.contoso.com end up pointing to the internal Lync front-end server. If you follow my blog post that describes how to configure external access without a reverse proxy, you can eliminate the ISA/TMG server shown here (again, can't stress enough that you SHOULD use a reverse proxy if possible).  Everything else points to the edge server. 

Certificate requirements should be relatively self-explanatory.  One exception is the internal SRV record.  You will notice that I used contoso.com instead of contoso.local for both the SRVLync clients will automatically query for an SRV record for contoso.com, but by default will reject the connection if the SRV record points to a different domain (ie. contoso.local).  You can override this with a registry key, but its likely easier if you create a FE.contoso.com A record (and add that name to the front-end certificate). 

Hopefully, this post will clear up the questions that often come up as a result of my Lync without a reverse proxy post.  If not, please let me know in the Comments section.

93 comments:

  1. Great article. I'm having trouble with the offline address book for external Lync clients not syncing, but content sharing now all works between internal and external clients. We are using a FE server and an Edge server without reverse proxy. Any ideas?

    ReplyDelete
  2. Hi Ken, great info. Similar to David, we to have issues with offline addressbook, but I believe it's related to the autodiscovery.domain.com not being published externally. Can you speak to how Lync uses EWS and the proper configuration for Lync when connecting both internally and externally? It is my understanding that Lync will get the proper EWS address internally, if it can't find autodiscovery.domain.local, but when Lync connects from external does it only look for autodiscovery.domain.com? hope my question makes sense.
    Thanks
    Kyle

    ReplyDelete
  3. Hi David,
    If the address book isn't working, make sure you've published an external DNS A record for the web services URL for your front-end. Also, your front-end external web services certificate needs that web services URL in its list of names. You should be able to browse to (ie) https://lyncweb.domain.com from the outside. It will come up blank, but that's OK.

    Ken

    ReplyDelete
  4. Hi Kyle,
    Lync will use EWS and autodiscover to show your conversation history and recent voicemails. The address book has no dependency on Exchange or autodiscover. To answer your question about autodiscover, it will be looking for autodiscover.domain.com, not domain.local. As long as Outlook works properly from outside via autodiscover, Lync shouldn't have any issues. If you're having Lync address book issues, see my above comment to David.

    Ken

    ReplyDelete
  5. Thanks Ken, maybe some clarity on my part may shed some light on my original question. We don't have Outlook configured at all for Outside connectivity. Not even OWA. (I know, I know I'm trying to change some mind). I just want to confirm what it is I need to change as we don't have a test environment to validate changes on. So enabling Autodiscovery for the externalurl in Exchange wont break anything on the inside.

    Thx
    Kyle

    ReplyDelete
  6. Hey Kyle,
    If you're having Lync address book issues, it won't have anything to do with Exchange autodiscover. So, any changes you make to Exchange won't fix your address book issue, but could cause issues for Outlook, if not done correctly. My advice is to leave Exchange alone.

    If autodiscover isn't working outside, the only effects you should see in Lync is lack of conversation/call history. You should be able to download the Lync address book.

    Ken

    ReplyDelete
  7. Hi ken. This is Luis from spain.

    I've beeing deploying a lync FE server and edge server. We have same internal and external domain. xyz.es. My topology is more over like that:

    FE:
    slync.xyz.es Front End server. Internal ip 192.168.x.y
    lync.xyz.es Front end external web services. Dns in our public dns servers. We have natted the public ip 8080 and 4443 to the internal IP

    Edge:
    server: lyncedge.xyz.es. One Internal Ip in the same lan as the FE. Other three private ip from DMZ in the other NIC. Nat in three public ip,s as follow
    sip.xyz.es 443, 5061 ext ip to dmz ip.
    Webconf.xyz.es 443 ext ip to dmz ip.
    av.xyz.es 5061,443,50000-59999 ext ip to dmz ip.

    Public dns: srv records to sip.xyz.es
    Nothing at the moment to meet.xyz.es, dialin.xyz.es.

    I pass the ocsonlinetest, all green. i can login and view presence and IM but no audio or video calls, sync address book, sharing desktop etc.

    The FE external site has an internal cert from our CA and maybe I need a public certificate.

    What things I lost without a reverse proxy?

    Could you please give me some advise to see it working from our ext users?

    Thank you very much. My mail is luis@airoc.es

    ReplyDelete
  8. Hey Luis,
    I want to confirm some things: when you say you're natting the public IP 8080/4443 to the front-end, are you saying you've got a rule that takes 8080/4443 from the internet and forwards it to 8080/4443 on the front-end? If that's the case, then that's wrong. You need to NAT the public IP 80/443 to 8080/4443 on the front end. Plus, you need a public cert on the front-end for External Web Services. If either of those are done incorrectly, you will have issues with address book.

    As for A/V issues, it sounds like you're having firewall port issues, or possibly IP routing issues on the front-end. Make sure you only have a default gateway set on the external interface, and use ROUTE ADD to set routes for your internal interface.

    Ken

    ReplyDelete
    Replies
    1. Hi Ken,

      I have added new Ip address and Natted to 1 Public IP. its working but we are not able to logn on Lync Mobile Client.

      is there anything that i need to do. remember please we dont have reverse proxy installed in Office.

      Waiting for your reply.

      Thanks
      Amit.

      Delete
  9. hi Ken.

    Sorry, It was late when I try to explain....

    I have the 80 and the 443 natted to the 8080 and 4443 to the Front End server. I`ve asigned a Public cert to the external web services and I´ve restarted the two servers, FE and Edge.

    Now the Audio video is working, We can share the desktop, etc.

    The problems now is the meet or webconf. Do I need the TMG to publish this services?

    Thank you very much Ken.

    ReplyDelete
  10. Hi Ken. I have some problems with my address book. I received an error after 10-20 minutes from login.

    Thank you very much.

    ReplyDelete
  11. The three URLs you need to publish via TMG/ISA (if you have one) are meet/dialin and lyncweb (as per my post). If you don't have TMG/ISA (one is highly recommended), then follow my post on External Access without Reverse Proxy.

    ReplyDelete
  12. Luis,
    If you're getting an error about not being able to download the address book, its likely because you don't have an external DNS A record for lyncweb.contoso.com (as per this blog post), or you're not sending traffic for lyncweb.contoso.com to your front end (either via ISA/TMG or direct).

    Ken

    ReplyDelete
  13. This was a decent blog i just wish everything was in one place. I wouldnt expect to find the DNS entry needed in the comments area.

    Thanks

    ReplyDelete
  14. Hi Ken.

    I have a simple question for the last diagram shown above. You have mentioned a different public IP for each of your URLs. In practice, is it necessary to publish each service using its own unique IP address. Can it not be public using, say, just one IP address?

    Beside that, you also mentioned that clients need to be able to connect from internet to FE server on port 4443. Isn't port 4443 used only for FE to Edge Synchronizationa and therefore doesn't need an external firewall mapping but just an internal DMZ firewall entry?

    Thanks,
    Animesh

    ReplyDelete
  15. Hi Ken,

    Thanks a billion for this info. I have two questions...
    1. Most of our clients (including ourselves)don't have an internal DNS zone for external domain. No one ever explains how to get external Lync access when all you have is a contoso.local. Got a walkthrough on that?

    2. Can external access be done w/o Edge server or at least an Edge server on the same box as the FE?

    Thanks,
    Manny

    ReplyDelete
  16. Hi Animesh,
    You don't have to use a unique IP for each of the access/webconf/AV services. You can use a single IP for all of them if you wish. It's better to split them if you can, because you will be using standard ports (443) for accessing them all. In secure locations, this could be the difference between between a solid connection and nothing at all.

    As for the web services, external clients will talk to the reverse proxy via 443, but the reverse proxy should translate it to 4443. That's because there are 2 different websites on the front-end, one meant for internal users (via 443) and the one meant for external users (via 4443).

    Ken

    ReplyDelete
  17. Hi Manny,
    If your public DNS zone only exists externally, then you can create an internal DNS "pin point" zone that only includes the necessary SRV records to function properly. See the section called "Automatic configuration without split-brain DNS" at this link: http://technet.microsoft.com/en-us/library/gg398758.aspx

    As for external access without edge or colocated on the front-end....sorry, that's not possible. The edge server has to exist, and it must be on a separate server. No way around it. People have tried, and can usually succeed at getting basic external IM working, but external web conferencing and A/V simply won't work without an edge.

    Ken

    ReplyDelete
  18. Thank you for taking the time to document this.

    I am currently working for a not-for-profit organization which, at this time, does not have a DMZ. The budget to establish a DMZ is set for the end of next year. Other than security concerns (obviously), are there technical reasons why I cant configure a NAT to an edge server that is sitting on my internal network?

    Thanks again for your help!

    Brian

    ReplyDelete
  19. Hi, Ken, it's Manny, again. But this time I just wanted to thank you for taking of your time to answer my questions. If by any crazy chance we should meet, I'll invite you to a cup of coffee (if you drink it, of course). ;-)

    ReplyDelete
  20. Hi Brian,
    Other than security concerns, there isn't much stopping you from having your edge in your internal network. Its not explicitly supported by Microsoft, but I've gotten it to work well in the past.

    Ken

    ReplyDelete
  21. Hi Ken,

    great information I succeded establish connection from outside to our edge, working fine.

    Now just to update with the new mobility services :-)

    just one question, is it possible to publish the visio diagram so I can quickly update my documentation ?

    many thanks for your help

    ReplyDelete
  22. Hello, again, Ken; it's Manny. Hope you had a good Christmas and New Year's.

    I ran into some confusion with single URL/IP for SIP/WC/AV vs 3 separate URLs/IPs. Our company doesn't have enough IPs for all 3 and only have one available IP. Does this mean my choice is clearly 1 URL/1 IP or can I do 1 IP/3 URLs?

    Also, public certs. Can I use a single multiple SAN cert for all URLs; such as sip.contoso.com, lyncweb.contoso.com, wc.contoso.com,etc.?

    Or MUST I have have at least 3 separate certs (1 SANs, 2 singles)?

    Thanks so much for this info. You seem to be the only person I find that discusses these things clearer.

    ReplyDelete
  23. Hey Manny,
    Had a nice relaxing Christmas/New Years, thank you very much.

    If you don't have enough external IPs, then you will only have a single externally facing IP/URL (sip.contoso.com).

    There's nothing stopping you from using a single cert for both the edge server and the reverse proxy. In this example, your certificate should have SIP.contoso.com as the CN, and lync.contosot.com/lyncweb.contoso.com as the SANs.

    Hope that clears things up!
    Ken

    ReplyDelete
  24. Ah! That does clear it up. You're the man! If I was going to go with no reverse proxy (I realize you strongly advise against it), at the Certificate Wizard on the first installation, should I uncheck "Web services external" for the future or keep the default of all checked and in the future when I want to implement external access without reverse proxy, get my third-party cert, come back to the Certificate Wizard and assign the new cert to "Web services external"?

    I guess what I'm trying to say is, would it make any difference if leave the box checked or not in case a client decides to want external access in the future?

    My Christmas was relaxing as well...nothing but Call of Duty: Modern Warfare 3 for a week and a half. :-p

    Cheers!
    Manny

    ReplyDelete
  25. Hey Manny,
    I would just assign the one cert to all the services, and if they go with external access in the future, get the new cert for external services. Having said that, if you're using a 3rd party provider for all your certs now, you won't have to revisit in the future, because it should all be taken care of already.

    Ken

    ReplyDelete
  26. Sigh! When it rains it pours. I didn't want to bother you again, but I was told that we can only do a 3-leg perimeter. Where I'm confused at is this Microsoft book on Lync Server 2010 showing me a diagram where both the internal and external NICs are in the same subnet (172.16.1.0) and they say not to have the internal NIC connected directly to internal network.

    Yet everyone else online says that the EXT and INT NICs CANNOT be in the same subnet!!

    Help me, Obi-wan, you're my only hope! Can I or not have both NICs on the same subnet (I realize the Int NIC won't have a gateway and all)?

    You've been a life-saver. Don't know how to thank you!!

    Manny

    ReplyDelete
  27. Hey Manny (young Padawan),
    Although not supported by MS, I've been pretty successful with having both NICs on the same subnet. You won't have a GW on the internal NIC as you said (and you need to setup static routes for internal subnets) but it should work OK.

    Ken

    ReplyDelete
  28. Sweet! I knew you'd have the answer! Now, I can do it but in YOUR expert opinion, SHOULD I do it that way or do it the MS way (connect INT directly to internal network)?

    I am able to do that while still using the 3-leg perimeter config so it will be fine but I want your blessing on what I should do.

    Manny

    ReplyDelete
  29. If you can have 2 separate subnets in the DMZ, that's the best way to go. Having one NIC in the DMZ and the other directly attached to the internal network will work fine, but might make your security guys nervous. Its preferable to having both NICs in the same DMZ subnet, though.

    In my opinion, do whatever it takes to make sure your edge NICs are on two separate non-routable subnets. That's supported by MS.

    Ken

    ReplyDelete
  30. Hi!

    http://i.technet.microsoft.com/gg399001.bff393a4-31c9-4b48-90fb-241ed75f8065%28en-us,OCS.14%29.jpg

    Looking at this diagram, am I correct when assuming I'll need 3 TMG servers if I implement the internal/external firewalls with TMG FE/BE configuration?

    Can I skip the reverse proxy TMG and provide its functionality with either the FE or BE TMGs?

    ReplyDelete
  31. Hi guys,

    I have a question that should be fairly straight forward, but can't seem to find any answers to. I'm just in the process of setting up my edge server and doing DNS. I'm stuck on the external SRV records.

    Suppose my internal domain name and SIP domain name is mycompany.local (eg. lync users are named username@mycompany.local). Suppose my public domain is mycompany.com.

    When I create my public SRV records, should they reflect my public domain name (eg. _sipfederationtls._tcp.mycompany.com or _sipfederationtls._tcp.mycompany.local). Or both?

    ReplyDelete
  32. Anonymous (Jan 10, 2012),
    Yes, you can use the external TMG server to provide reverse proxy services for your web publishing needs.

    Ken

    ReplyDelete
  33. Hi Scott,
    You shouldn't use your internal domain name (mycompany.local) as your SIP domain. This will prevent anybody on the outside from reaching you, because anything.local isn't publically routable and can't be used in external DNS. You should change your SIP addresses to the same as your email address (recommended, but not strictly required). Once you got that straightened out, you will use mycompany.com in your SRV records.

    Ken

    ReplyDelete
  34. So, I've been using your articles to construct my edge environment because my company doesn't want to set up a reverse proxy server. I've got the edge server set up with a single IP address for external access.

    We've forwarded all the ports to take care of the reverse proxy problem and the nonstandard ports when using a single IP address, and now we only have a public certificate with lync.domain.com, and no other SAN's. This certificate's been applied to the external edge interface, and the external web services interface on the front end.

    I'm guessing as long as we set up the dialin and meet simple urls as lync.domain.com/meet & /dialin, that we should be fine. Or am I horribly mistaken and we're going to need to get some additional SAN's added to that certificate in order for the simple urls to work since it's actually the front end server that hosts them.

    Here's a breakdown of our topology:
    -Sonicwall forwards ports 80 to 8080, and 443 to 4443 for the front end server.
    -1 Public certificate with lync.domain.com applied to external edge interface, and external web services on front end
    -External Edge interface uses 1 IP address, it is not privately natted because our Sonicwall is stupid like that, and so it has a Public static IP address applied. We are using port 5061 for sip, 444 for webconf, and 443 for AV.
    -Using windows firewall for edge server to do all port blocking/allowing.
    -Set up simple urls in Lync for lync.domain.com/meet, and lync.domain.com/dialin
    -lync.domain.com point to single static ip address of edge server
    -We still have to figure out how to make our public DNS create those SRV records.

    I'm guessing the only issue I may run into is getting the simple urls to work correctly.

    ReplyDelete
    Replies
    1. Hey Chris
      You'll run into issues with address book downloads etc. because your cert also needs to have lyncweb.domain.com (assuming you're following this blog post). Meet/Dialin will work fine as you have it though, but I'm sure you'll want everything working right. :)

      Also, your edge server won't be using the cert for lync/lyncweb. It should be its own cert using just sip.company.com.

      Ken

      Delete
  35. Regarding Lync Edge with no DMZ or RP. What might one's Edge server NIC config look like. All of the best practice docs and guides only ever speak to RP w/ DMZ scenarios... Suppose my Edge and FE server are just sitting on a regular old class C together...?

    I've configured my Edge wth 3 internal IPs (192.168.10.173, 174, 175), and pointed each external service to one (sip -> 173, av -> 174, webconf -> 175). Each service has its own separate IP.

    Ken, this blog has been really helpful. Since No RP and no DMZ would be a fairly common config, I'm more than happy to share my layout if it can help other users on your site!

    ReplyDelete
  36. I have a question on the Certs for this setup.

    My Firewall will be acting to change 80 to 8080 and 443 to 4443 so I will need a SAN for the FE server with lync and lyncweb. Do I only need the Edge cert to have SIP or does it also need to be a SAN with SIP, WC and AV?

    Thanks,

    Todd

    ReplyDelete
    Replies
    1. Hi Todd,
      Your edge server will need either just SIP if you are only using 1 IP address for the external interface, or SIP/WC (not AV) if you're using 3 IPs for the external IP (as defined in your topology).

      Ken

      Delete
    2. Your Blog has been a very good resource and thanks for the quick response.

      Delete
  37. This comment has been removed by the author.

    ReplyDelete
  38. Hi Ken,

    I am using Natting with New IP Address in fE. my all the web services are worikng but Lync Mobility is not runing without reverse Proxy.

    Please help me to get it done.

    Thanks
    Amit

    ReplyDelete
    Replies
    1. Hi Amit,
      I've heard that the new IP address option breaks Lync mobility (that post was written long before mobility was an option). If you can't do the 8080/4443 redirect, then you won't have any other option than to install a reverse proxy.

      Ken

      Delete
  39. Hi Ken

    Is it possible tu use different port than 443 for the reverse proxy.
    I haven't got a lot of internet adresses and i want to use an IP witch already has a reverse proxy service on port 443.
    How can i tell the internet client to use the port 444 for example.

    Sorry for my english, i am not native.

    Damien

    ReplyDelete
    Replies
    1. Damien,
      I don't believe you can change the port that Lync uses for its external web services. The Lync client is hard-coded to look for services using HTTP/HTTPS, and can't be changed. You may notice an option to change ports in the Topology Builder, but that's for communication between the reverse proxy and the front-end. It has no effect on client connectivity.

      Ken

      Delete
  40. Hi Ken, great article!

    I need your help about a test lab. I have one edge server, one director server and two front end server. I configured the folowing external URL:

    dirwebext.mydomain.com (director external url)
    fe1webext.mydomain.com (front end 1 external url)
    fe2webext.mydomain.com (front end 2 external url)

    I must publish all these url ? I need one IP address for each external url?
    I dont know how the client determine what url to use!

    Can you explain to me please?

    Thank you

    ReplyDelete
    Replies
    1. Hi Anonymous,
      You need to publish the external web services URLs for the two front-ends and the director. Look at Jeff Schertz' blog entry on the subject: http://blog.schertz.name/2011/03/publishing-lync-director-web-services/

      Ken

      Delete
  41. Thanks for the post. Let me present my issue. I have 1 FE and 1 Edge box with no reverse proxy. I have 3 public IPs natted as follows:

    sip.mydomain.com - 64.64.1.121 --> 10.x.x.121
    webconf.mydomain.com - 64.64.1.122 --> 10.x.x.122
    av.mydomain.com - 64.64.1.123 --> 10.x.x.123

    All the private IPs go to the external NIC on my edge server.

    Proper ports are open.

    External Web Services are on a second NIC on the FE with 10.x.x.124 assigned. IIS is properly bound to this IP only. Firewall NATs 64.64.1.124 to 10.x.x.124 and forwards 80/443 to 8080/4443 respectively. Lyncweb.mydomain.com resolved to 64.64.1.124. A certificate from GoDaddy for lyncweb.mydomain.com is in assigned.

    Connectivity is smooth and all features work. My only issue right now is web conferencing address not working. Also, client coming through the Edge can't access the address book. If I go to httP://lyncweb.mydomain.com i get a 403 error, so at least I know it is hitting the server. If I do httpS I get nothing. I have my simple url set as webconf.mydomain.com.

    I am confused. Is my simple URL supposed to be something else? Did I screw up a DNS record somewhere? I'm basically going in circles trying to figure this out.

    ReplyDelete
  42. I need a tool to let my external users to test their NAT / Firewall ports (80, 443, 5061, 50000-59999, 3478). They often go to a network which has not been configured (unblocked ports), and they can't access. I want a tool so they can test it when a sign in problem occurs. Is there anything like that?

    ReplyDelete
    Replies
    1. There's a great tool created by fellow Canadian Lync MVP Curtis Johnstone that does exactly what you need. Get it here: http://www.insideocs.com/Tools/MOCLogin.htm

      Ken

      Delete
  43. Hi Ken

    Question

    We have an existing IP-PBX (3cx) the we are replacing with Lync. The existing server uses sip.mydomain.com internally. Our AD Domain is mydomain.com which is also the external domain. My UAG Direct Access users can connect to all our file shares and our internal sharepoint site without any issues but when they try to run the Lync client it fails to connect. If I modify the host file to point sip.mydomain.com to the edge server it works. Non-DA users work without any problems. Meet works also. External DNS server has an A record for sip.mydomain.com pointing to edge external IP. My thought is that the client is seeing the internal DNS addresses and failing to connect. Does this make sense? Any help would be appreciated.

    ReplyDelete
    Replies
    1. Hi Ken,
      I don't know much about DirectAccess, but it does sound like your external users are getting the internal IP address from DNS. From my Bing/Google search, I found a reference to adding sip.mydomain.com to an NRPT exception list to ensure your users get DNS for sip.mydomain.com from the outside.

      Ken

      Delete
    2. Hi Ken

      I applied the changes in UAG and that fixed teh problem. Your blog is one of the best tools for getting Lync up and running.

      Delete
  44. Hey Ken,

    It's Manny, again! It's been a while and that's because our Lync deployment had been running perfectly fine (thanks to your guidance, of course) but now they want me to implement mobility services.

    Since I couldn't find a guide on your site I tried searching elsewhere (because the MS deployment guide left me hanging again) but they aren't as clear as I've seen you can be so I'm hoping if it's not too much trouble, help?!?

    I'm stuck with the modification of the certificates. I'm using "LyncWeb" for external web services as you showed and after installing the Mcx bits and requesting a new internal cert it wants to replace "lyncweb" with "lyncdiscoverinternal". Is this right?

    So I don't make this any longer, simply put is it the fact that all I need is to "add" "lyncdiscoverinternal" to the Server default and Web services internal cert and for the Web services external add "lyncdiscover", since I'm using a separate 3rd party 5 SAN pub cert? I'm confused with "lyncdiscoverinternal" and "lyncdiscover" having to be on the same cert for both internal and public certs. It seems obvious that the one with the "...internal" suffix is naturally only for internal.

    Thanks again for assistance! I don't think our company would actually have any deployments of Lync without your insight, ha ha.

    Manny

    ReplyDelete
    Replies
    1. Hey Manny,
      Lyncdiscoverinternal should only be on the cert that is visible internally. Lyncdiscover should be visible internally and externally. What is supposed to happen is that internal clients who connect via lyncdiscoverinternal should be redirected to the external IP for lyncdiscover. This way, when mobile clients switch between the corporate network and the public internet, they won't be prompted to reauthenticate.

      And, I'm glad that I was such a great help for you. Happy its working well!
      Ken

      Delete

  45. Hi Ken,
    How r u.. hope you are doing well.. This is manish and I read your article, its really great article and clears most of my confusion.
    I have one question regarding public Certs.

    I am deploying Lync in an organization with one Front end server (lync standard edition). Currently they are using it internally and everything is working fine.

    Now they want external Access. For that I was planning to deploy lync edge server, they have one public IP only.

    So i selected 1FQDN/1ip option, and given the name UC.Domain.com, here domain.com is the external domain name.

    FE Server name is FE.Domain.local
    Edge server name is EDGE.DOMAIN.local

    I am planning to purchase SAN Certificate with alteast 5 names, I am confused that which names I should include in the certificate. Please suggest, I will really appreciate if you can help me on this... Thanks in advance. Thanks.

    One final question I seen that for internal NIC card also it was asking certificate, is that also required? Internal domain name is domain.local and external is domain.com.

    Thanks.

    ReplyDelete
    Replies
    1. Hey Manish,
      The edge server external cert will have the name you defined for it in your topology. If you run through the Certificate Wizard, it should populate the cert request with the required name. If you selected a single external IP, then your cert will only need one public name. The internal certificate only requires the edge.domain.local name. You are still going to need a second external IP for web services, which should proxy through a reverse proxy server before going to your front-end.

      Hope this helps.
      Ken

      Delete
  46. Hi Ken, Great write ups on Lync. It really has helped me out!
    I do have one issue:
    External users are working great. AV, Presentation, file transfer etc from the outside to internal. From internal to external everything works except desktop and program sharing. This is in a Lync 2013 server and client environment. Any ideas?

    ReplyDelete
    Replies
    1. Hey Marco,
      Make sure that you have port 5062 and 443 open from your front-end pool to your edge server internal interface. That's often the cause of the issue.

      Ken

      Delete
  47. Ken,
    I got a question between your FrontEnd and Edge box. Do you have those on a totally different network than what your clients connect to on the frontend side? Or a better way do you have a second IP on the front end box for local connections?

    ReplyDelete
    Replies
    1. The front-end only needs a single IP to communicate with both the edge and internal clients.

      Hope this helps,
      Ken

      Delete
  48. Ken,

    I have set everything up and all is working, except for Poll, Whiteboard, and Powerpoint share.

    I have a public Cert on FE external webservices specifying sip, webconf, pool, meet, lyncdiscover. I am using 1 IP for all sip, webconf, and av. Edge is up and running. Kind of hit a wall here.

    ReplyDelete
    Replies
    1. I forgot to mention that screen share, and program share both work internally and externally.

      Delete
    2. Check your topology to see what URL is being used for external web services on your pool. Polls, whiteboarding and Powerpoint sharing use this URL. You need to publish that URL on your reverse proxy like you did for meet/dialin. Also, the cert you use on your reverse proxy needs that URL as well.

      Ken

      Delete
    3. Ken,

      That would probably be the solution if we were using a reverse proxy. This article was setup Lync without Reverse Proxy, as I have done. So, I'm still a little confused and would love your further input.

      Delete
    4. You still need to publish the FQDN of your external web services. In the example I've shown in this article, I've used lyncweb.contoso.com. You need to make sure that name is available to the outside world, and connections route to the front-end via port 8080/4443 (as per my article on external access without reverse proxy).

      Ken

      Delete
  49. Hi Ken,
    I have problem connecting to external meet url. Error 404-Resource cannot be found.
    Here is my scenario:
    One FE Server with 2 ip address. 1. 172.X.X.X (internal) 2. 10.X.X.X (DMZ)
    Simple URL on my FE are:
    https://dialin.internal.local
    https://meet.external.com
    https://meet.internal.local
    Internal Web Service URL:
    https://lync.internal.local
    External Web Service URL:
    https://lyncweb.external.com

    My external URLs are pointing to single public IP on my firewall. I have NAT rule to redirect port 80/443 traffic to my external IP on FE(10.x.x.x) which i have configured to listen on port 80/443. Followed your instruction according to your post http://ucken.blogspot.in/2011/01/lync-external-web-services-without.html .

    I went through your post and all the comments but still there is something missing with my configuration.

    Krishna

    ReplyDelete
  50. Hi Ken,

    I have followed your guide for setup the lync web service without proxy. It worked fine on the https://meet.xxxx.com/user/xxxxx

    My environment as below: -

    LYNC FE 10.x.x.163
    LYNC Edge 10.x.x.165 (internal), 172.x.x.165 (sip.xxx.com), 172.x.x.166 (wc.xxx.com), 172.x.x.167, all 3 DMZ IPs are natted with each public IP.

    Currently, I'm having few issues:
    1. I have a problem with downloading presentation content,
    2. Mobility seems to be not connecting.. My iphone and android cant get connected

    Doesn't it work without deploying Reserve Proxy?


    Looking forward your reply.
    Ray

    ReplyDelete
  51. Hi Ken,


    I am rookie in this topic, so maybe u can help me.

    I have this problem "The Web Proxy filter failed to bind its socket to IP port 443. This may have been caused by another service that is already using the same port or by a network adapter that is not functional. To resolve this issue, restart the Microsoft firewall service. The error code specified in the data area of event properties indicates the cause of the failure."

    I need to publish lync mobility but when i need the port 443 is already used by direct access in my UAG and i get the trouble. What can i do???

    Thanks

    ReplyDelete
    Replies
    1. Hi Bryan,
      I'm assuming you're trying to use UAG to publish Lync mobility? Unfortunately, its not supported at this time. I know, I know. Silly that MS dropped TMG and their other edge web interface server product doesn't support Lync mobility. You can try this workaround listed at: http://stoknes.wordpress.com/2012/12/19/uag-as-a-lync-reverse-proxy/

      Ken

      Delete
  52. Hi Ken,
    In my environment is made of one Edge and one FE server. I am using Cisco ASA 5500 series to forward 443/80 requests to 4443/8080.

    Lync Mobility works fine when corporate network or when public internet. The problem I am having is when a device is using corporate wifi and public internet (3G). Lync client reports "cannot connect to the server, verify your network connection or server address. Please check them and retry".
    I am not sure where to start with troubleshooting this and have not found any posts of anyone reporting this problem. Can you offer any help on where should I be looking?

    ReplyDelete
    Replies
    1. Its not clear what is or isn't working from your post. Does Lync Mobility work when you're in the office? Or just out of the office?

      Ken

      Delete
  53. It works when out of the office, it works when using Corporate WI-FI only, but it does not work when the devices are in corporate WI-FI and 3G network at the same time. The devices are iPhone 5.

    ReplyDelete
  54. An update, I created an internal DNS record with private IP address 10.x.x.x, lyncweb.domain.com which is the same FQDN as the external webservices and that broke Mobility over corporate WI-FI,so I backed out the change and now the Lync internal still does not work. (yep I made it worst)

    Some more DNS info on my setup:
    lyncweb.domain.com -> A record with external IP address (hosted by provider)
    Lyncdiscover.domain.com -> A record with external IP address (hotsted by provider)
    lync.domain.com -> A record with private IP address (FQDN of Lync FE server)
    lyncdiscoverinternal.domain.com -> A record with private IP address.


    ReplyDelete
    Replies
    1. Is your deployment a Standard Edition deployment? Just checking to make sure, cuz I notice you didn't post the internal web services DNS, which would be OK if its Standard Ed. Your internal DNS should point lyncweb.domain.com to the external IP (which should be your reverse proxy), so that's correct.

      In summary, this is how things should look for mobile clients:
      Internal DNS zone for domain.com
      -lyncweb.domain.com points to external IP of reverse proxy, which redirects to front-end pool
      -lyncdiscoverinternal.domain.com points to front-end server

      External DNS zone for domain.ocm
      lyncweb.domain.com points to reverse proxy then goes on to FE
      lyncdiscover.domain.com points to reverse proxy then goes on to FE

      Since things work over wifi already, I don't think you've done anything wrong. Doesn't make sense why it works over wifi in the office and 3G when out of the office, but not over 3G when in the office. Something is going screwy with the iPhone, I think.

      Ken

      Delete
  55. Hello,

    Great write-up! I just had a question on the FQDNs you used. You specified LyncWeb.contoso.com for the 'external base URL' but Lync.contoso.com for the simple URLs. Can the external base URL and the simple URLs be the same FQDN? I assume they can because the simple URLs all have extra virtual directories specified at the end (/meet, /dialin, /admin) and wouldn't conflict with the hidden external base URL.

    Or does that cause an issue with the different virtual directories in IIS (due to the different permissions or something)?

    Thanks for the clarification!

    ReplyDelete
    Replies
    1. I'm pretty sure the Topology Builder won't allow you to use the same URL for both the external URL and the external web services. You'll get a big red X.

      Ken

      Delete
  56. Hello Ken,

    Great articles!! But I've totally confused in DNS records and where to point it :\ Sorry for asking very simple question.

    I've deployed lync frontend, edge, and RP for mobility.

    Let's say our local domain as contoso.local, external as contoso.com. And I have 2 public IP's one for Reverse proxy external NIC, one for Edge NAT public IP. Do I need more Public IP?

    Sip domain is contoso.com. External web services URL-> lyncweb.contoso.com
    Edge is using NAT to use public IP(for.ex: 200.200.200.200) and access,webconf, a/v URL -> sip.contoso.com
    sip.contoso.com -> where to point from our external DNS?

    Simple URL: meet.contoso.com, dialin.contoso.com
    Where to point these records?

    SRV recors: 1) _sipfederationstls._tcp.contoso.com 5061 point to sip.contoso.com
    2) _sip._tls.contoso.com 443 point to sip.contoso.com

    Autodiscover: autodiscoverinternal.contoso.local points to lync front end
    autodiscover.contoso.com -> where to point?

    officewebapp: owa.contoso.com -> where to point?

    And finally I'll buy public certs for: contoso.com, sip.contoso.com autodiscover.contoso.com, owa.contoso.com, meet.contoso.com, dialin.contoso.com right? Is there any link missing?

    Any help would be greatly appreciated.

    ReplyDelete
    Replies
    1. SIP.contoso.com will point to your edge server's public IP.
      autodiscover should be Lyncdiscover, and that will point to your reverse proxy and get routed to your Lync front-end.
      Meet/dialin will point to your reverse proxy and get routed to your Lync front-end.
      OWA will point to your reverse proxy and get routed to your Office Web App server

      That should be it.

      Ken

      Delete
    2. Thanks Ken,

      Now I'm looking forward to buy public CA's.

      What if my Simple URL's as follows: https://contoso.com/dialin, https://contoso.com/meet? both counted as SAN? or only contoso.com is enough?

      What does Common name should be? Sip domain?


      Delete
    3. Configured Certificates on RP, Edge, Front end.
      But when I access Https://contoso.com/autodiscover/autodiscover.svc/root doesnt' work.

      Used https://www.testocsconnectivity.com it works on port 5061 but not works on 443 - 403 - Forbidden: Access is denied error appears.

      extweb.contoso.com points to TMG
      lyncdiscover.contoso.com points to TMG

      public certificate is - CN=sip.contoso.com
      SAN= sip.contoso.com, lyncdiscover.contoso.com, contoso.com, extweb.contoso.com

      also https://lyncfe.contoso.local doesn't work :(

      Delete
    4. Autodiscover is for Exchange, not Lync.

      Extweb/lyncdiscover/meet/dialin should go via TMG to front end over 4443. Follow the Lync over TMG implementation guide to the letter for this.

      Sip.contoso.com is the only one that should go to the edge. You should have only sip.contoso.com on that certificate. All the other names can go on the TMG server cert, starting with extweb.

      Ken

      Delete
  57. hello ken, i have a lync 2013 setup with internal domain as contoso.local how will i set up my DNS for internal communication if my lync topology is configured as contoso.com. for example _sipinternaltls _tcp, what will be the domain contoso.local or contoso.com

    ReplyDelete
    Replies
    1. The domain should be contoso.com. Ideally, your pool name should also be in the contoso.com domain as well, but if its standard edition, you're forced to use contoso.local. In that case, just add a DNS entry for SIP.contoso.com and point it to your front-end pool. Make sure you have SIP.contoso.com in your certificate on your front-end.

      Ken

      Delete
  58. Dear Ken,
    Could you please take a look on my problem?
    My aim is to correctly set Lync 2013 Environment.
    I have:
    FrontEnd
    ReverseProxy
    Edge
    OWAS (Web App Server)
    I want to have mobility with autodiscover. I prefer to use certificates with following settings, is it correct and will work as expected?:
    On the FrontEnd I would like to request (to internal CA) one certificate for ‘Server default’ and ‘Web services internal’:

    With following
    SN:
    lyncpool.domain.local
    SANs:
    lyncpool.domain.local
    FrontEnd.domain.local
    sip.domain.local
    lyncdiscoverinternal.domain.local
    Additionally, for external user access my approach assumes that I will request for ‘Web services external’ such SANs:

    SN:
    webext.domain.com
    SAN:
    webext.domain.com
    sip.domain.com
    lyncdiscover.domain.com
    owa-ext.domain.com

    I would like to use second (external certificate) on FrontEnd and on the Reverse Proxy for two purposes: FrontEnd external services and OWAS.

    Do you think this is possible and supportable?
    Do I need to have separate IP address for OWAS external acces?

    ReplyDelete
    Replies
    1. You shouldn't use sip.domain.local or lyncdiscoverinternal.domain.local on the internal side of your deployment. Always use the SIP domain name, so sip.domain.com and lyncdiscover.domain.com. If you use the Certificate wizard in the Lync Deployment Wizard, it should set all the cert names properly.

      You didn't specify if you're using a reverse proxy (I hope so). If so, you can use the same IP for OWAS, because the host header can be used to direct the HTTP requests to the internal OWA box.

      Ken

      Delete
  59. Hi Ken and thank U for replying . . .
    My internal domain is test.local and the external domain is test.com.
    I read your good solution to use external domain as primary SIP domain. As you said, in this situation FEpool name must be FEPool.test.com but now my FEPool name is FEPool.test.local because I installed the Lync . So I should change this name.
    How can I rename the FEPool.test.local to FEPool.test.com ?!!!

    ReplyDelete
    Replies
    1. Is your FE pool a Standard Edition pool or Enterprise? If its Enterprise, then you'll have to completely remove the pool and recreate it. If its a Standard Ed pool, then you can't rename it.

      Ken

      Delete
  60. Ken thanks for the article!

    We're having one issue with our setup. We have Edge, FE, and RP (Running Kemp). Our only problem seems to be that Audio/Video services will not work for external people that connect in with meet.domain.com This is also true if a Lync user connects via the client and tries to initiate a call. Thinking it maybe either internal DNS issues, or Firewall related.

    ReplyDelete
    Replies
    1. Usually, A/V issues are firewall related. Doublecheck that you've published the right IP address for your external A/V service, and check the firewall rules.

      Ken

      Delete
    2. Thanks for your reply! We have 3 external IPs *.*.181.227 .228 .229 nat'ing down to internal 10.0.3.227 .228 .229 for edge, webconf, and av.

      I'm allowing ports : 443 tcp, 3478 udp, tcp 20000-65355, udp 20000-65355, 5269 tcp, and 5061 tcp.

      Everything from my DMZ above can traverse to my FE.

      Also, we have 1to1 NAT turned on so that the above internals go out on the same external...could that be it?

      Thanks again!

      Delete
    3. NATing is allowed on the Lync edge. Just make sure you've checked the NAT box in the Topology Builder and entered the public IP address used by your A/V edge.

      Delete
  61. Hi Ken

    I have a problem. I have the services of Lync FE and WAC Working properly with LYNC 2013 , the problem is with the PowerPoint presentation to External level the Edge Server is working correctly, I mention it I have not a TMG or IIS AAR server for of the Reverse Proxy, I have it running a juniper . detail is that the reverse proxy for lyncdiscover , Lyncweb , meet and dialin have declared in the external DNS IP Pubic one point it to a later date after the reverse proxy by Juniper to ports 80 - > 8080 443 -> 4443 works part of the meetings, but mobility NO. On the other hand the service I got with another WAC Public IP and DNS record then apply a NAT rule 443 -> 443 , I commented that I apply and I https://office.domain.com/hosting/discovery shows the XML with their certificate , but for the Lync service is only loading and never shows the Powerpoint slides , I hope you can help me .. regards

    ReplyDelete