Lync Deskphones and Wildcard Certificates

A critical component of any Lync deployment is the deskphone.  While some users may be comfortable with using a headset/PC combo as their primary telephony interface, I've found that most users still prefer a deskphone.

However, getting a Lync deskphone to work with Lync can be a bit tricky if you aren't diligent about following Microsoft best-practices to the letter.  You may have a Lync environment that works perfectly well for computer-based Lync clients, but you may come across various connectivity issues when you plug in a Lync deskphone that does presence and Exchange calendaring. 

I recently came across a client who were having Exchange connectivity issues with their Polycom CX600 phones.  The Polycom CX600 is likely the most popular Lync deskphone. It provides a very slick interface into Lync and Exchange so you can see your presence, contacts and upcoming meeting information. It is also very cost-effective compared to other similar products.

When users signed into Lync on their CX600 (either via keypad or USB-PC integration), they were soon presented with the following error:

Microsoft Exchange integration unavailable.  Connection to Exchange is unavailable due to invalid network credentials.

The CX600 uses Exchange Web Services (EWS) and autodiscover to find the connection to Exchange.  If there are issues with either service, it will pretty much guarantee that the CX600 won't connect.  I verified that both EWS and autodiscover were working properly.

When I reviewed the certificate loaded on the Exchange Client Access Server, I saw that the common name (CN) was set to their public domain (ie. contoso.com).  The Subject Alternate Names (SAN) included all the required names.  Microsoft Lync documentation recommends that you do not use certificates with the CN set to a wildcard domain name.  You CAN use wildcards in the SAN, but the CN really should be a valid name.  In this case contoso.com is the same as *.contoso.com. 

The client replaced the certificate with one whose CN matched the externally accessible name of the CAS server (owa.contoso.com) as reported by Exchange.  They issued an IISReset, restarted the CX600 and the error went away.  They now have full connectivity to Exchange via the CX600.

I've seen variations on this many times on both Exchange and Lync.  If you're only using Lync PC clients, you may never notice any issues, but as soon as you bring deskphones and even mobile phones into the mix, these sort of things often come up. 

So as a general rule, if you're creating certificates for Lync or Exchange, DON'T use a wildcard as the first name.

Block Premium Rate Numbers with Dialing Rule Optimizer

I'm always on the lookout for ways to improve the Lync Dialing Rule Optimizer.  I got a request from a frequent user to add an option to block premium rate phone numbers.  Premium rate phone numbers are numbers that charge a higher than normal fee for calls...like those TV ads that promise incredibly hot women in bikinis are waiting to talk to you for only $4.99 per minute. 

The usual way to block these numbers was to program an exception for them in the relevant route regular expression.  I was on my way to figuring out how to programatically do this through the Optimizer when I stumbled upon this little gem of a post from Brian Rubart's UC Blog.  He came up with the brilliant idea to use the Lync Announcement and Unassigned Number service to block these numbers.  So, rather than just returning an uninformative fast-busy when someone tries to call a premium rate number, the Announcement service will tell the user why the call cannot be completed.

The only downside I can see to dealing with premium numbers in this manner is that its a setting that will affect all users.  There isn't a way to allow specific people to call premium rate numbers.

In the latest revision of the Dialing Rule Optimizer, you now have the option to use the Announcement service to block premium rate numbers.  All you need to do is to put a checkmark beside Block Premium Numbers.  It will create the relevant Powershell commands at the bottom of the resulting PS1 file. 

The Powershell commands will create the announcement using text-to-speech synthesis in the language of the selected country. You can modify the announcement text as you see fit. You can also modify the default premium number ranges or add your own if you wish.

An example is below.  Don't try to run these commands outside of the context of the Optimizer-generated script.  It relies on variables set earlier in the script:

New-CsAnnouncement -Parent $AppSrv.Identity -Name 'Announce_BlockedNumber_NA' -TextToSpeechPrompt 'The number you have dialed is prohibited due to corporate policy. If you need to reach this number, please notify your manager.' -Language 'en-US'

New-CsUnassignedNumber -Identity 'PremiumRate_NA_1' -NumberRangeStart '+19002000000' -NumberRangeEnd '+19009999999' –AnnouncementService $AppSrv.Identity -AnnouncementName 'Announce_BlockedNumber_NA'

New-CsUnassignedNumber -Identity 'PremiumRate_NA_2' -NumberRangeStart '+19762000000' -NumberRangeEnd '+19769999999' –AnnouncementService $AppSrv.Identity -AnnouncementName 'Announce_BlockedNumber_NA'

If you are so inclined, instead of using text-to-speech, you can use an audio file (in WAV/WMA format). Import the file using the Import-CSAnnouncementFile command as below...

$a = Get-Content ".\GreetingFile.wav" -ReadCount 0 -Encoding Byte

Import-CsAnnouncementFile -Parent ApplicationServer:redmond.litwareinc.com -FileName "WelcomeMessage.wav" -Content $a

...and then assign it to the announcement using the -AudioFilePrompt switch in the New-CSAnnouncement command. 

You can also send blocked calls to a SIP URI like sip:yournamehere@contoso.com or a phone number like "sip:+14255551212@litwareinc.com;user=phone", by using the -TargetURI switch in the New-CSAnnouncement command. That way, you can shame your users verbally when they try to call blocked numbers. Fun times!

If you have any suggestions for additional features, corrections to the premium number list, or if you can help me correct the Google-translated text I used for the other languages supported by the Optimizer, please drop me a line.

Verifying Lync Trunk Translation Rules with your Phone

Greetings all.  It's been a while since the last real blog update.  This past summer was quite busy both work-wise and life-wise, so the blog posts fell by the wayside.  Consider it a summer hiatus, like TV.  As fall brings a new TV season, it also brings new blog posts, so read on....

If you've used trunk translation rules in Lync (and if you've followed my Enterprise Voice Best Practices series, you should be), you may have discovered a very annoying omission in the Voice Route Test Case window. 

Once you've created all your normalization rules, its a good idea to validate your dial plan and voice policies by running some numbers through the Voice Routing Test Case window.  The voice routing test case dialog box can be accessed from any of the tabs in the Voice Routing section of the Lync Control Panel.  Just click the little downwards facing chevron to expand the window.  The window will stay active no matter which tab you click on, which can be handy for testing changes as you go.


I usually find it best to select the checkbox beside Populate from user and selecting a valid Enterprise Voice-enabled user, so you can be sure you're testing the right dial plan and voice policy.

You'll notice that when I plug in a test 10-digit local phone number for a Vancouver based Lync deployment, it shows that it applies the correct normalization rule, picks the correct usage and the route.  If you've used the Dialing Rule Optimizer or followed my best practices for creating routes and trunk translation rules, a trunk translation rule should strip the +1 from the number before sending it to the PSTN.  However, the test case results do not show the trunk translation rule that would be applied to the number. 

The omission of the trunk translation rule from the results window can lead to the mistaken belief that the number isn't being sent out correctly.  It can also lead to general confusion, heart palpitations, sweaty palms and mild to severe incontinence.  I believe this is a serious omission that limits the usefulness of this otherwise great tool. 

Normally, the only way to verify the number is being formatted correctly once it leaves Lync is to use the Lync Logging Tool or IP gateway logs (if you've got one) to sift through until you find the information.  Either that or if the call completes successfully, that's a pretty good indication things are working as expected.  However, if you happen to have a Polycom CX500/600/700/3000 series Lync phone or Aastra Lync phone, you can easily validate what number is sent to the PSTN. 


When you dial a local number, the normalized number will be shown first (which will always start with +1), but the actual number sent to the PSTN will be shown in a smaller size below.  The first screengrab shows what it looks like when you dial a local number that should have the +1 stripped out.  The second shows a long distance number that should only strip the +.

Local Call

Long Distance Call

If you happen to have a Polycom or Aastra Lync deskphone, this is a great way to validate your trunk translation rules.  Hopefully, Microsoft will update the Voice Test Case app to include trunk translation rules in the future.

Many thanks to Tim from Rolling Thunder, who pointed this out to me during a discussion about trunk translation rules this morning.