Ken's UC Blog Turns 1!

It was a year ago that I first dipped my toe into the blogosphere.  I really had no idea what I was going to blog about, outside of a few vaguely formed thoughts.  At first, there was very little traffic.  Every day, I would get excited over seeing anybody visiting my blog.  Now, I've built up what I hope is a fairly respectable set of posts that seem to regularly turn up in searches and I get just under 10,000 page visits a month.

I hope I can continue providing helpful information about Lync and Exchange UC related in the next year and beyond!
Here are some of my site stats collected over the last year....

Top 5 Visits by Country
USA        38%
UK            9%
Canada      6%
Germany    4%
Australia    3%

Top 5 Browsers
Internet Explorer  60%
Firefox                 19%
Chrome               13%
Safari                    4%
Opera                   1%

Top 5 Operating Systems
Windows    90%
Macintosh    4%
Linux            1%
iPad             1%
iPhone          1%

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 +)
3. Use an MSPL script to re-route incoming calls to the appropriate auto-attendant.

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.  

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.

Configuring Ringback in Lync Response Groups

When setting up Response Groups in Lync, you might want your callers to hear ringing rather than some sort of hold music (either the default provided by MS or custom).  I've seen people looking for a solution in the forums without much success.

What I did in this situation was to download a .WAV file of a ringtone (known as "ringback" in telephony lingo) and set that as the hold music for the hunt group.  Lync will play back the file continuously, so an audio sample of a single ring will suffice.  The ringtone I downloaded had no pause in it, which meant the caller would hear a constant ring without a pause. That was fixed by inserting a silent stretch into the .WAV file.  Remember to save it as an 8 or 16 kHz, mono 16-bit WAV file.  Here's a sample for North America (right-click and Save-As for best results).

File this under "So-simple-and-why-didn't-I-think-of-that".

Dialing Rule Optimizer Goes International

Since the Dialing Rule Optimizer was extended to create a total end-to-end Powershell script for North American users, it was relatively trivial to add similar functionality for other countries.

Now, the Dialing Rule Optimizer can provide a Powershell script that will create all the rules necessary for an Enterprise Voice deployment for users in Australia, Germany, Netherlands, Norway, Sweden and the United Kingdom with more on the way.  I've even attempted to convert English to German (thanks to Google Translate...so any blame on translation accuracy can be pushed that way). 

Having never dialed a phone in the UK or Germany, I've had to make some assumptions:

• any local phone number dialed from within a given area code does not have to include the area code
• phone numbers outside the local area code must start with 0, followed by the area code, then the local number
• international numbers must be preceded by 00 then the country code/area code/local number

Because of those assumptions, I didn't have to perform any of the complex calculations necessary for North American numbers.  Since the dialing rules aren't expected to change over time, you can't enter an email address for non-North American rule updates.  Also, since this is designed as a Lync-only feature, you can't (nor should you need to) create rulesets for the Dialogic or Audiocodes gateways.

Please let me know if my assumptions are incorrect, or if you can offer corrections to my German translations. 

If the demand is there, I will create dialing rules for other countries as long as someone can help me understand the local dialing rules and can help with language translation.  Things I would need to know:

• Local number format
• National number format
• International number format
• Service number format
• Premium-rate number format

For anyone interested in helping with language translation, here is a list of words/phrases I would need translating:

"Internal"
"Local"
"National"
"International"
"Service"
"Invalid site ID"
" number normalization for "
" routing for "
"Normalization rules for "
"Enter the Site ID to apply the dialing rules for "
"Multiple application pools found. Please select the application pool to apply call block/park"
"No default PSTN gateway found. You must define a PSTN gateway in your topology and assign it to this site before running this script."
"Removes"
"Adds"
"and"
"for"
"country/area code"
"country code"
"calls from"
"The number you have dialed is prohibited due to corporate policy. If you need to reach this number, please notify your manager."

Major Upgrade to Dialing Rule Optimizer

If you've used the Dialing Rule Optimizer, you probably know how easy it makes it to create your North America least-cost routing rules for Lync.  After much work, I'm proud to unveil new functionality that will automate the process even more.

Originally, the Optimizer created a simple text file that you would copy and paste into Lync Powershell.  It would create the phone usage, route and trunk translation rules necessary for least cost routing for a given site.  If you input the name or IP address of your PSTN gateway, it would set it in the route, but if not, then the route would not be associated with a gateway.  The process was not very tolerant of errors either.  If you mistyped the name of the PSTN gateway, much of the script would fail.  The original output got you started, but you were still left to your own devices for pretty much everything else.

With this latest release, the Optimizer will provide you with a ready-made Powershell .PS1 script that will do the following:

1. Prompts you for a site to apply the script to
2. Checks for a PSTN gateway assigned to the site.  If one isn't found, the program will quit.
3. Creates a site-level Voice Policy (unless one already exists).
4. Creates standardized site-level normalization rules for local/long distance/international as per my Normalization Best Practices post.  If your site is in Canada, creates normalization rule for 310 toll free calls.
5. Creates separate PSTN Usages for Local, National and International and adds them to the Voice Policy as per my Usages and Routes Best Practices post.
6. Determines the PSTN gateway associated with the site. If no PSTN gateway is defined in the topology, you'll have to assign the routes and trunk translation rules manually after you set one up.
7. Creates routes for local, national, international, toll-free, and service numbers (411, 911 etc).  If your site is in Canada, creates an additional route for 310 calls.
8. Assigns those routes to the default PSTN gateway in the site.
9. Creates trunk translation rules for local calls, national and international calls.  If you entered an external dialing prefix on the web page, it will take this into account as well.  If you select the SIP Trunking option, then the trunk translation rules are not applied.

Preparation for the script is also much simpler.  All you need to do beforehand to get the most out of the script is to ensure that your sites all have a PSTN gateway assigned.  The script looks at the site and will try to apply the routes and translation rules to the default PSTN gateway assigned to that site.  If one isn't available, the script will still work, but you will have some manual labour to do afterwards.

Detailed Instructions

1. Ensure all your Lync sites have a default PSTN gateway assigned to it
2. Go to http://www.LyncOptimizer.com
3. Pick your country from the drop-down list.  Only a few are available now, but more will be added over time.
4. Enter the area code information for the site you want to apply the script to
5. If you have to enter 9 (or some other digit) to get an outside line, enter it in the appropriate box.
6. If you are using a SIP trunk that accepts E.164 phone numbers, select the Using SIP Trunk option.  If selected, the program will not create trunk translation rules.  All numbers will be sent to the next hop formated as E.164. Note: Don't select both an external access number AND SIP trunk options.  The two options are mutually exclusive. 
7. If you want Lync to block premium rate phone numbers (like 900 in North America) for all users, select the Block Premium Numbers checkbox.
8. If your North American local dialing area supports 7-digit dialing, select the 7-Digit Normalization checkbox.  If you're unsure if your local dialing area supports 7-digit dialing, leave this blank. Doesn't apply to other countries.
9. To receive updates should the ruleset change, enter your email address.  Only applies to North American users.
10. After pressing Generate Rules, wait a minute for the rules to be generated.
11. The program will provide 2 files.  The .PS1 file will do almost everything to get you up and running.  The .TXT file provides only the least-cost routing rules for North American users, and assumes you will be doing most of the other work.
12. Save the .PS1 file to your Lync server, start up the Lync Management Shell and run the script.
13. You will be prompted for the site to apply the rules to (as below).  Select the appropriate site and in a few seconds you'll have all you need to get started.

Here's what the Optimizer looks like for North American users:

Here's what it looks like for international users:

The International Optmizer doesn't have to do the same level of processing that it needs to do for North American numbers.  There is a clear deliniation between local and long distance calls, which makes creating rulesets much simpler.  Since the dialing rules aren't expected to change over time, you can't enter an email address for non-North American rule updates. Also, since this is designed as a Lync-only feature, you cannot (nor should you need to) create rulesets for the Dialogic or Audiocodes gateways.

Run the Optimizer once for each site, and apply the resulting .PS1 file.  The finished output should take care of all your basic external dialing scenarios using my best practices as laid out in my Enterprise Voice Best Practices posts.  You will just have to add normalization/routing rules for internal use as you see fit.

Below are some screenshots of what a virgin, never-touched Lync Enterprise Voice implementation will look like after applying the script (this example uses Toronto as the location).

Dial Plan

Voice Policy

Routes

Usages

Trunk Configuration (If SIP Trunk Option NOT Selected)

Blocked Premium Numbers (if selected)

The blocked premium number list is customized for each country.  The actual announcement can be customized either by using text-to-speech or audio files.  See this blog post for more information.
To provide failover and least cost routes for multiple sites, simply add the appropriate PSTN usages to your Voice Policies as desired.  Use this post as a guide for how to provide least-cost and failover routing between multiple sites.

If you still prefer to do things manually, or you already have a voice deployment you're happy with, the original script format is still included as a .txt file.  It will create the bare minimum PSTN usages and routes for least-cost routing.

I hope you find this useful.  Please let me know if you have any problems or questions.  If you find a bug in the script, PLEASE let me know so I can fix it.

Lync Enterprise Voice Best Practices - Extensions

In earlier posts, I've tried to outline what I consider to be best practices when it comes to Enterprise Voice in Lync.  There hasn't been a lot of detailed guidance on the subject, and while "my" way is certainly not the only way to do things, it has worked well for me and the other Lync consultants in my company.  If you haven't read my other posts on the subject, here they are in order:

E.164 Formatting

Normalization

Usages and Routes

In E.164 Formatting, I briefly touched on how to manage extensions for companies that don't use Direct Inward Dialing (DID) numbers for their users.  DIDs are usually known as "direct numbers", where you don't have to dial a central number to speak to a receptionist (or auto-attendant) to reach your target user. For cost, business or technical reasons, a company may not use DIDs for their internal users.  Instead, they assign everyone an extension off a main office number.

So, how to best handle this sort of situation in Lync? As mentioned in the E.164 formatting post, you should always use E.164 format for all your phone numbers.  For extensions, this should be:

+<country code><area or city code><local number>;ext=<internal extension>
Example:  +15197772222;ext=2345

For consistency more than anything, every number in a given office should have the same main number, followed by a unique extension.  Don't give in to the urge to just assign extensions to your users.  You will make your life difficult down the road when you have to deal with multiple locations and special routing scenarios.  Ideally, each office should use unique extension range, even if it is technically allowed to use the same extension (assuming the main number is different for each site).  For example, while the below example is allowed because the entire phone number is unique, even though the extensions are the same:

Bob at Waterloo Office: +15197778888;ext=2345
Lara at Toronto Office: +14163334444;ext=2345

it's better to have something like this:

Bob at Waterloo Office: +15197778888;ext=2345
Lara at Toronto Office: +14163334444;ext=3456

This way, you can easily create normalization rules so users can dial by extension across the company (even though they will likely dial by name most often).  Examples:

^(2\d{3})$ --> normalize to +15197778888;ext=$1
^(3\d{3})$ --> normalize to +14163334444;ext=$1

For outbound calling, the PSTN likely won't recognize the ;ext= format in the user's Caller ID and may default to show the main office number, but if it doesn't work, you can always use the Alternate caller ID in a route to make sure the main office number is sent as the Caller ID.

One thing to stress is that you cannot use the office number alone for any purpose in Lync if you've used that number for your extensions.  If you're using +14163334444;ext=3xxx for your users, you cannot use +14163334444 by itself for your Exchange auto-attendant or Response Group.  If you try this, all inbound calls will fail with an error along the lines of "485 Ambiguous".  If you find yourself in a situation where you are getting "485 Ambiguous", try using Tom Arbuthnot's Get-LyncNumberAssignment script that will help locate any rouge numbers that may be assigned to UM, common area phones etc.

If you've set up extension dialing and are getting the dreaded "485 Ambiguous" when trying to reach someone, its likely because you have defined your office number somewhere without an extension. 

To properly handle your auto-attendant or Response Group, it should be assigned an extension just as you would for any other user.  To make sure it will answer all inbound calls, create a pool-level dial plan that converts the main office number to the proper extension for your auto-attendant/response group.  For example:

Main office number: +12127778888
Main office response group: +12127778888;ext=2000

The pool-level normalization rule would be something like this:

^(12127778888)$ --> +12127778888;ext=2000

All calls coming into the main office number should be automatically routed to the appropriate auto-attendant/response group.

In conclusion, I hope this post answers a lot of the questions that come up with how to best handle extensions in Lync.  While there is nothing stopping you from assigning just the extension to the user, I truly believe that starting off with a consistent deployment around E.164 will make your life easier and will help prevent issues down the road.

UPDATE 22-Jul-2011:

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 +.

There are several workarounds:

1. If you are using a 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 +)
3. Create an MSPL script to forward the incoming number to the autoattendant directly.

I've confirmed this is the expected behaviour for Lync.  I've made my case to the right people, so maybe we'll see a change in the future.

Lync and Dialogic Troubleshooting Tips

If you've setup Enterprise Voice with Lync, you will often have to use some sort of media gateway to connect your Lync infrastructure to the PSTN (unless you're using a direct SIP provider, of course).  One of my favourite media gateways is the Dialogic DMG 2000.  It's extremely flexible and easy to setup.  I've been on more than a few deployments that used Dialogic gateways, and I'm constantly amazed at how quickly you can be up and running.  I usually tell the customer it may take an entire day to get it working right, but its always taken less than an hour from plugging it in to full inbound/outbound Lync PSTN calling.

This post isn't about how to setup a Dialogic to work with Lync.  Dialogic already has all the documentation (even a sample configuration file) to get you going in that respect.  I'm assuming you've already gotten Lync working with a Dialogic and you've got the latest firmware revision.

UPDATE (21-Sept-2011) - It appears that the www.dialogic.com/microsoftuc site is not working.  The documentation and sample config.ini used to be located at http://www.dialogic.com/microsoftuc/DMG2000_Lync_Config.zip.  The documentation can be viewed at Scribd via http://www.scribd.com/doc/58959088/Lync-DMG2000-Setup-1.
Once things are running, you may encounter some rather odd issues that could leave you scratching your head.  Here are a few of my experiences and how I resolved them.  Keep in mind that while the solutions worked for my client, it may not work for yours.  Also, make sure you backup your current configuration, so you can revert back to it should any of the changes you made break things.

Lync Attendant Console and RGS Formal Participation Policy

It's been quite a while since I've blogged about Lync. I've been a very busy boy trying to finish renovating my basement before the weather turns too nice to be stuck indoors. Thankfully, the crappiest spring I can remember has allowed me to get a lot done. Between that and my day job, it hasn't left me with much free time or energy to blog.

Last night, I was helping a client complete their migration from a legacy PBX to Lync Enterprise Voice. Their receptionist was going to use the Lync Attendant Console to manage incoming calls via a simple Response Group.  Since there were a few people who rotated into the receptionist role throughout the day, we needed a simple way to ensure that calls would only go to the person currently on reception duties.

Enterprise Voice and Communicator for Mac 2011

I've never been a Mac fan (probably due to that chip I'm POSITIVE Microsoft installed in my skull back in the day).  However, since they can be found in the corporate environment from time to time, it was inevitable that I would eventually have to deal with an issue with it.

Communicator for Mac 2011 provides pretty much the same features as the PC Lync client, including Enterprise Voice.  A few Mac in our office have tried to use the Enterprise Voice functionality, but it never seemed to work as advertised.  The documentation kept referring to a phone icon in the client, but all our Mac users had just a microphone icon in its place.  They could only make Communicator-to-Communicator calls.

With me being the Mac non-expert that I am, I dealt with the issue in the best way I knew how:  Google for help.  That turned up nothing (this was a few months ago), so I did the next best thing: I ignored the issue.  However, a client had the exact same issue, and thanks to their help (Yanick from Distributel), we've finally got a solution.

Yanick did some digging and found some references to a requirement for populating the Business phone number for Enterprise Voice users to allow Communicator for Mac to work. I found this excellent post from Keenan Crockett at Pointbridge. I won't rehash what he says there, because it describes exactly what to do, with one small but important omission: The phone number you enter in Active Directory seems to have to be in E.164 format (ie +15552221111).

Our phone numbers were entered as 15552221111, and even though we do have a valid, functional Company_Phone_Number_Normalization_Rules.txt file that successfully normalizes numbers to E.164 for Lync, it wasn't enough for the Mac client.  Once Yanick and I added the + sign in front of all our numbers, and followed the directions in Keenan's blog (Update-CSAddressBook, delete client address book files etc), the Mac client's screen switched from this:

To this:

Our Mac users are now able to dial phone numbers from within Communicator for Mac 2011.  We're almost completely out of the woods, however we are experiencing one odd issue. Whenever we type a number in the dialpad, Communicator crashes with exception EXC_BAD_ACCESS after entering anything more than 6 digits. We can dial successfully if we select the user's phone number from our contact list.  We've got the latest updates installed. Has anyone else seen this behaviour?