Friday, July 22, 2011

Lync Bug with Incoming E.164 Phone Numbers?

If your company uses internal extensions instead of DIDs for your users, you may have come across my blog post on how to best setup Lync Enterprise Voice for internal extensions.

There appears to be an issue with using my method of using the main office number as a base for all internal extensions in certain circumstances. The issue seems to arise when the incoming phone number coming from the PSTN is prepended with a plus sign (a properly formatted E.164 phone number). When Lync sees an incoming call that starts with a +, it assumes the number is properly formatted and does not apply any translation rules. Since my method relies on a translation rule to add a ;ext=<ext> to ensure the incoming call is going to a unique number, Lync will return a 485 Ambiguous (because there are many numbers with the main number as a base) and drop the call.
This only occurs in situations where incoming calls are prepended with a plus sign. This will typically occur when using SIP providers or PSTN gateways (AudioCodes, Dialogic etc) that prefix incoming calls with a +.  I verified this with a client that has both a PSTN connection via a Dialogic (that doesn't add a + to incoming calls) and a SIP provider that does add a + to incoming calls).
There are several workarounds:
  1. If you are using a Direct SIP provider, they may be able to not send the + to your Lync server. Call your provider and ask if this is an option.
  2. If you are using a PSTN gateway or IP-PBX that is sending a +, you should be able to easily modify the incoming rule to drop the + sign (as your rule is most likely explicitly adding a +)
I've confirmed that this behaviour is by design.  I've brought up these cases as an example to the proper people, so maybe we'll see this changed in a future release.  

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 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 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  It doesn't really matter what the URL is (clients never see this), but I will use in this example.  For deployments with multiple front-ends and/or directors, I would use something a bit more descriptive like

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

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 and  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 and  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 and 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 instead of contoso.local for both the SRVLync clients will automatically query for an SRV record for, 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 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.