Monday, December 20, 2010

Lync Enterprise Voice Best Practices - E.164 Formatting

For all the strengths of Lync in the Enterprise Voice department, there doesn't seem to be a lot of practical advice is how to properly design voice routing. Everytime I have to design voice routing for a client, I constantly end up second-guessing myself on the best way to go about it.  Microsoft's assistance in this area has improved since the OCS R2 days, but administrators are still left to their own devices when it comes down to the nitty-gritty details like:
  • Internal phone number formatting and normalization
  • How to best configure routes and PSTN usages
For the first bullet point, administrators can struggle with questions like "What format should I store numbers in Active Directory?", and "How should I normalize phone numbers inputted by users"


For storing numbers in Active Directory, you should save every number in E.164 format.  E.164 is an internationally recognized standard for phone numbers.  The standard is:
+<CountryCode><City/AreaCode><LocalNumber>;ext=<ext>
The country code is 1-3 digits long, while the city/area code and local number length can vary. The ext= portion is usually only used for companies with internal extensions. Public phone numbers in E.164 format look something like this:
+14162223333 for Toronto, Canada
+60321345678 for Kuala Lumpur, Malaysia
The Canada country code (and also for US and a good portion of the Caribbean) is 1, while Malaysia's country code is 60.  The area code for Toronto is 416 (and 905, 647, 289), while Kuala Lumpur's city code is 3.  Local numbers in Canada are 7 digits long, while KL's are 8 digits long (but are 6 or 7 digits long in other parts of Malaysia).

When inputting phone numbers in Active Directory, you can add separators as you see fit for readability. So, +1 (416) 222-3333 is OK, as is +60.3.2134.5678.

Users with internal extensions, and no direct number (DID) should use the ;ext= component. Start with the central number for the office and add the extension, like +19052223333;ext=555.  Don't store the number as just the extension.

Do not add country-specific routing codes for international calls in your Active Directory, like 011 or 00. These routing codes are not part of the E.164 standard. Also, do not exclude the country code from your numbers using the rationale that all your users are in the same city.

If you don't use E.164, you're likely going to have issues.  One real-world example is a Canadian company that stored their international numbers with 011 at the start (the international routing code for Canada). While it made clicking-to-dial from Communicator/Lync easier, it meant that users from other countries that used different international routing codes couldn't dial the number without throwing an error.

Another North American company had a PSTN carrier that required that local calls not include the long distance code 1. Since all their Enterprise Voice users were located in one city, they felt it was easiest to just not include the 1 in all their Active Directory users phone properties.  Once they expanded Enterprise Voice to other locations in another province, they found that the new users couldn't dial the original users due to the lack of a leading 1 (which is required for long distance calls in North America).

Even if you never plan on expanding to a different city or country, it's important to stick with E.164 formatting. If you federate with another company and publish your phone numbers, its entirely likely they won't be able to click-to-dial if you don't use E.164 phone numbers, simply because the other company can't anticipate whatever internal numbering scheme you came up with.

When you can assume that every incoming phone number will be formatted consistently, its relatively trivial to create trunk translation rules to add any required routing digits such as 011 for international calls, or removing the 1 for local calls before passing the call to the PSTN or next gateway.

"But wait!" you say.  "I have to remove the 1 for local calls and the list of local numbers is way too long to work with. How do I go about getting over that hurdle?" Simple! Use the Lync Dialing Rule Optimizer as discussed in Dialing Rule Optimizer for E.164 Phone Numbers and Least Cost Routing in Lync.

If you don't want to go through the hassle of fixing your internal phone numbers in Active Directory, I suggest using the Company_Phone_Number_Normalization_Rules.txt.  This file is filled with regular expressions that will convert any invalid phone numbers found in Active Directory to properly formatted E.164 numbers during the address book generation phase. You have to create the rules yourself based on your requirements, but there is lots of help out there to get you started (plus there are samples in the Sample_Company_Phone_Number_Normalization_Rules.txt).  You can find it in C:\Program Files\Microsoft Lync Server 2010\Web Components\Address Book Files\Files.  For a good overview of the Company_Phone_Number_Normalization_Rules.txt, see Jeff Schertz's blog entry on the topic.

At pretty much every deployment I ever do, I start with these basic normalization rules in the Company_Phone_Number_Normalization_Rules.txt file, which tends to capture many styles of AD phone numbers:
\+?1(\d{10})+1$1
\+?1(\d{10})\D+(\d+)+1$1;ext=$2
\+?(\d{6,14})+$1 
\+?(\d{6,14})\D+(\d+)+$1;ext=$2


If you stick with E.164 from the start, you will avoid the potential for dialing issues down the road.

My next post will discuss how to handle phone number normalization in Lync.  After that, I'll discuss route building.

For another great post on this topic (relating to OCS, but still very applicable to Lync), see this post on Doug's DTMF blog.

Tuesday, December 14, 2010

Finally! Exchange 2010 OWA Redirect Bug Fixed!

Ever since the release of Exchange 2010 SP1, there have been numerous reports of users being prompted that they have to be redirected to another server, instead of the silent redirect that had worked like a charm until SP1.  I blogged about this in September after I experienced the issue for myself.  Since then, it's been one of the most-read pages on my blog.

I've just received word that the issue has finally been fixed in Exchange 2010 SP1 Rollup 2.  This KB article describes the issue and the confirmation that it's been fixed by RU2.

You can get Rollup 2 here.

Thursday, November 25, 2010

"Optimized for Lync" Devices

Over the years, I've used any number of devices to connect to Communicator/Lync.  I've used everything from cheap-o $20 headsets to some high-end OCS-specific phones. For the most part, these devices have worked out OK.  Some required a bit of fiddling to make work right, while others just worked with no fuss or bother. I've had headsets that make themselves the primary communications device without asking and not relinquish this to the previous primary device after unplugging it, which was a headache in Communicator. Others just worked and didn't bring much attention to itself, which is really the ultimate goal, isn't it?

My absolute go-to office audio device for the past few years has been the Plantronics Savi Office Convertible headset. It connects to both my PC and my PSTN desk phone and works like a charm.  It's a very good desktop headset solution.  With DECT 6.0 wireless, I can wander a good distance from my house and still maintain a good connection. The sound quality is excellent.  I do have a few gripes with it, though.  I can't use the over-the-ear earpiece because of my apparently oddly-shaped ears (earbuds NEVER fit me). I have to resort to the over-the-head headset. Plus, the earpiece bothers my ear after wearing it for an extended period.  Another minor issue is the lack of wind cancellation technology. In the summertime, I like to work outside on my patio in the "office hammock".  The slightest breeze gets picked up by the headset and annoys the person on the other end (maybe they were upset because I was working from a hammock and they weren't). Granted, the Savi Office isn't meant for use outdoors, so I can't really knock it for that.  Overall, its been the one thing I keep using out of my pile of headsets.
My summer office. Beer fridge well out of reach.
For my cell phone, I've been using the BlueAnt Z9i. It's a Bluetooth headset that works with both mobile phones and PCs. I've got it paired with both my laptop and mobile phone. It's extraordinarily tiny and unobtrusive. For mobile use, it's excellent.  Great volume and voice isolation. However, I found it lacking when I used it with Communicator/Lync on my laptop. It sounded fine for use with PSTN or mobile communications, but the sound quality just didn't match up to the higher fidelity of Communicator/Lync's wideband audio. Sure, it was primarily designed for mobile use, but I never used it much for Communicator/Lync because of the lack of wideband audio.

I recently became fortunate enough to gain possession of a good variety of Plantronics devices to showcase at a presentation I'll be doing on Lync.  I have the Calisto 540 desk phone, the Calisto 420 speakerphone, the Voyager PRO UC, the Savi 430 and the Blackwire 420. The one thing all these devices have in common is they are all optimized for Communicator/Lync.
Installing and using all these devices is as simple as plugging it into an available USB port. To have a little fun, I decided to see what it would be like to install all the devices and see how Lync handles it. Windows 7 x64 picked up and installed the required drivers for all without asking for input. Lync detected each of them and named them appropriately. Selecting which device to use was very simple.  I could easily select a default device for all my calls and switch between them seamlessly while on a call.  Lync even gave a specific speakerphone-like icon to the Calisto 420 speakerphone.

A few quick notes on each device:
  • The Blackwire 420 is a very comfortable, nice-sounding binaural USB-corded headset with integrated volume, mute and call pickup/hangup buttons. It folds flat into a little carrying case, making it ideal for travel. This replaces my old Plantronics one-ear headset, which didn't really travel all that well.
  • the Calisto 420 speakerphone really just a speaker with 360-degree microphone that will fit in your hand. Its perfect for ad-hoc conference calls and is fairly portable.
  • The Voyager PRO UC is replacing my BlueAnt. It fits over-the-ear, connects to my mobile phone and my PC at the same time, has great wideband audio quality for Lync calls and is super-comfortable to wear (and doesn't fall out of my good-for-nothing ears). As for how it deals with extraneous noise, like wind on the hammock, I can't tell yet. It's November, and definitely not hammock weather in these parts. My only wish is that it were DECT 6.0 so I could wander far away from my PC, as I tend to do while on long conference calls. It charges via a USB cable only, so while its not great if you're in the office, its fine if you're on the road....which this is meant for.
  • The Savi 430 has the same form-factor as the Voyager PRO UC, but it doesn't do Bluetooth. It does have DECT 6.0 for my wanderings and a nice desk charger, just like the Savi Office. Now if I could take the DECT 6.0 and the desk charger option of this headset and the Bluetooth capabilities of the Voyager PRO UC and mash them together, then that product would be the absolute perfect headset for all my needs.
  • Last but definitely not least is the Calisto 540 desk phone. It's a perfect, inexpensive deskphone for people who still want a standard phone experience. It connects via USB to your computer and is driven by Lync (it won't work on its own like other more expensive phones). You can use it like a regular deskphone, or you can use Lync to dial, answer, hang up etc. This phone has the capability to really make a strong showing in the corporate world. It's simple, inexpensive, doesn't require its own power supply or network connection, and still provides users with a rich Lync experience.
My troublefree experience with all these devices has shown me what the whole "Optimized for Lync" thing means when it comes to devices.  I used to think it merely meant it would do wideband audio. I now realize it also means trouble-free installation and use, which is more than I can say for some of the non-Lync optimized headsets I've tried.

Plantronics really has done a great job with their Optimized for Lync line of products. In my opinion, they are the ones to beat in this segment of the market. Whether or not you choose Plantronics devices for your company or yourself, I believe that any device you pick should have the Optimized for Lync logo on it. Doing so might cost you more than your typical $20 POS, but in the long run it will pay for itself in ease-of-use, better performance, reduced helpdesk calls, and lower frustration levels.


In case of lawyers, please note that the opinions presented here are mine alone and are not representative of my employer or any other vendor, Plantronics included.

Friday, November 19, 2010

Response Group Changes in Lync

The Response Group Service (RGS) is a basic hunt group/interactive voice response system included with OCS/Lync.  While it doesn't have the features of a full-fledged call center application, it is still extremely handy for a lot of companies that don't require (or want to pay for) a separate solution. 

Response Groups in Lync haven't changed significantly since the OCS R2 days. You still have to create and manage the hunt group/IVR workflow via a web-based console that is separate from the main Lync Control Panel.  There is a Workflow tab within the Response Groups section of the Control Panel, but clicking on the Create or edit a workflow button will open up a separate IE window where you manage workflows. The interface is very similar to the OCS R2 version. Why they couldn't port the webpage into the Silverlight Control Panel is beyond me. It couldn't be that difficult to translate. 

Wednesday, November 10, 2010

Lync Telephony - Corporate Interest is Running High

I'll be the first to admit that I've got a certain level of bias when it comes to Microsoft products. I'm pretty sure they installed some sort of mind-control chip in my brain when I worked there as a technical support guy back in the MS-DOS 6.2 days. If there is a chip rattling around my skull, it does malfunction from time to time, because I've never been afraid to knock MS for putting out some truly dreadful crap over the years.

When Microsoft does get it right, it gets it right in a big way. Exchange is one of those things. It seems to be the gold standard for corporate email systems, and with good cause.  Its extremely stable, rich in features and most importantly, easy to use across many different platforms (PC, web, mobile). My perception could be skewed, because as an Exchange/OCS/Lync consultant, I'm not going to be called into a company for help with Lotus Notes (unless its to help migrate to Exchange).

For all my love of OCS, I noticed that most of the companies that wanted to use it weren't really interested in the Enterprise Voice functionality. They would use OCS for its terrific IM capabilities, easy-to-use client and admittedly so-so conferencing features (I knocked a bunch of points off mainly for the poor Live Meeting interface).  I always thought they would organically grow into Enterprise Voice, but it didn't happen as often as I thought it would.  Overall, I thought OCS was a fantastic product, but there were some obvious holes that made it less than ideal for replacing a PBX.  The biggest omission was call admission control and any real resiliency for voice communications.  Companies saw that, and maybe felt that OCS was a little too version 1.0 to trust for their telephony needs.

Lync Server 2010 changes all that. Its a truly unified communications platform. OCS's missing features (call admission control, voice resiliency etc) are now in place, and Live Meeting has been dropped in favour of a single client that combines all the features of Communicator and Live Meeting in one very easy-to-use package. I don't think any of MS's competitors can claim to provide all the features of Lync under one product SKU (I'm looking at you, Cisco).

Sure, my mindset could be affected by my Microsoft bias (damn you mind-control chip!).  However, in the recent few weeks, I've noticed a dramatic change in the inquiries and requests for proposals coming my way at the consulting company I work for. Rather than just being interested in the basic IM and web conferencing features, almost every corporate customer is keenly interested in exploring Enterprise Voice.  Recent partnerships, including the one with Polycom for enterprise video conferencing, means that Lync can very well be the all-encompassing corporate unified communications platform it intends to be.

It reminds me of that not-so-long-ago time when most corporate customers were extremely wary of moving their telephony systems into the TCP/IP network space. Almost overnight, the wariness was replaced by enthusiasm as it was shown to be a safe and reliable way to reduce costs, administration overhead and provide improved features.

Have we reached a similar tipping point in regards to Lync?  It seems as though Microsoft may have gotten this product release right, and the corporate world is ready to give them the chance to prove that Lync can be the future of telephony. Will Lync be the Exchange Server for telephony? Time will tell, but I've got a good feeling about this....

Friday, November 5, 2010

Lync Call Recording

Greetings all, its been a while since I've updated this blog and for good reason.  I just got back from a week-long trip up to a VERY remote mine site above the Arctic Circle in Alaska.  I did an Exchange 2007 to Exchange 2010 migration, including UM. It was cold, dark much of the time but starkly beautiful.  Not somewhere I'd consider living, but was pretty cool to visit.

While I was away, things definitely happened on the Lync front. It's gone RTM (as I'm sure everyone already knows). It was frustrating being so remote, because the Internet connection just wasn't fast enough for me to download the bits.  Now I'm back home and able to really get into things.

I had a customer call the other day talking about deploying Lync.  One thing he was very interested in is the Call Recording feature. He wanted to have the ability for users to record calls with clients for documentation purposes.  I hadn't spent much time (well, no time) with call recording in Lync, so I figured now was a good time to check it out.

Friday, October 22, 2010

Music on Hold for Lync Clients

Yet another nice new feature in Lync is the ability for Enterprise Voice enabled users to choose their own music that's played when they put someone on hold.

From the Lync client, click on the Options "gear" icon and go to Ringtones and Sounds.  If the logged on user is enabled for Enterprise Voice, the last option should be Play music on hold.  Users not enabled for Enterprise Voice won't see the option to use music on hold.  For enabled users, you'll notice that it's greyed out by default.

To enable this setting, you need to edit your Lync Client Policy to allow music on hold. Client policies replace the Group Policy Objects that were used in Communicator 2007 R2 to enable/disable features in the client. These policies can be global, or they can be limited to groups or even individual users.

You manage client policies via Lync Powershell.  Assuming you haven't created any client policies, there will be a single one called Global.  To see the current settings of the Global client policy, type:
Get-CSClientPolicy Global
The setting we're interested in is EnableClientMusicOnHold.  By default, this is set to FALSE.  Set it to TRUE by typing:
Set-CSClientPolicy Global -EnableClientMusicOnHold:$TRUE
Log off and back onto the Lync client and the Play music on hold dialog box should be enabled.  Interestingly, there doesn't seem to be a way to allow the user to check or uncheck this option. It's either enabled or disabled by the policy, and can't be modified by the user.

If you've previously installed beta versions of Lync (pre-RC), you'll notice the path to the music file is probably C:\Program Files (x86)\Microsoft Office Communicator\Media\DefaultHold.wma.  If you browse to this location, you'll find it doesn't exist.  The actual path to the default hold music file is C:\Program Files (x86)\Microsoft Lync\Media\DefaultHold.wma

Now, when you put someone on hold, they will get a nice soothing melody while they anxiously await your return. Note that this setting is computer-specific, meaning that if you have Lync running on multiple machines, you'll have to make sure the path is set correctly on all computers, and the media file exists in that location.

If you don't want to use the default hold music, you're free to use any piece of music that suits your taste. The caveat here is that the selected music file must be in WMA format.  Bitrate-wise, I've tested a few different files, and it hasn't had any trouble with them - variable or constant bit rate, stereo and up to 192 kbps.  Your mileage may vary.  If you're looking for a tool to convert MP3 to WMA, I suggest Audacity.

If you don't trust your users to select appropriate hold music, you can assign an audio file using the MusicOnHoldAudioFile parameter in Set-CSClientPolicy.
Set-CSClientPolicy -EnableClientMusicOnHold:$TRUE -MusicOnHoldAudioFile pathtoaudiofile.wma
If you assign this setting, users won't be able to change the hold music. To allow users to change the audio file, you have to clear the setting by assigning the $NULL value or "" to the MusicOnHoldAudioFile parameter.

Friday, October 15, 2010

Least Cost Routing in Lync

NOTE (June 2011):  While the general idea around least cost routing hasn't changed, the process required to use the Dialing Rule Optimizer has been greatly simplified and enhanced since I originally created this post.  See this post for the most up-to-date information on how to best use the Dialing Rule Optimizer.  I do encourage you to read on for general background information on how least-cost routing works.

Companies that have a number of offices spread across a wide geographical area often wish to leverage something called Least Cost Routing to reduce their telephony costs.  Least Cost Routing is the process of selecting the cheapest telephony route for a given call.  If you're a company with offices spread over a wide area, it makes sense to route your calls so that you avoid long-distance changes whenever possible.

Say you are in a company with offices in Toronto, Vancouver, Dallas and Miami. If you're in the Toronto office and you need to call someone in the Miami area, it can be much cheaper to route your call over the WAN to your Miami office and then out to the PSTN. What would have been a long-distance call is now a local one.

Traditionally, it's been extremely tedious to implement Least Cost Routing effectively. You need to obtain lists of all the local calling areas for all your offices, massage the data into something your telephony system understands, and then import that data.  Keeping track of changes can be challenging at best, and near impossible at worst. Publicly available lists such as those from http://www.localcallingguide.com/ make obtaining the raw data relatively easy, but manually working that data into something manageable is extremely difficult.


For instance, look at the local calling area for Dallas, TX.  The results include 1737 individual lines of data!  Sure, the data is setup for easy import into a spreadsheet, but turning this into something usable will take a very long time. What happens when there are changes? How do you keep track of new additions or corrections?  What if you have to do this for a company with offices across the continent?  How many rules will your device accept before it reaches its limit?

Some people might take a simpler approach and route all calls for a given area code through that office. For Dallas, they might look at the 1737 rules and decide to route all calls to the 214, 469 and 972 area codes through the Dallas office. Sure this works in some cases (like New York City), but most telephone numbers cannot make local calls to every number in that area code.  So, you would be routing some calls over your WAN (which incurs data costs) to your Dallas office and have to pay long-distance anyways.

How can someone easily setup Least Cost Routing without giving themselves an administrative aneurysm when faced with a challenge like this? Well, guess what?  I've got a solution.

Using the data from http://www.localcallingguide.com/ and the ease-of-administration inherent in Lync's Powershell command structure, I've created a web-based tool called the Dialing Rule Optimizer that does almost everything you need to implement Least Cost Routing in your Lync deployment.

First, you need to make sure your Lync deployment is complete. Specifically, make sure you've defined and published the PSTN gateways for all your offices using Topology Builder.  Make sure the PSTN gateways are associated with the appropriate mediation server.  Also, make sure that all your normalization rules normalize numbers to the E.164 standard ie. +15195551111.

Once published, you need to add the PSTN gateways as Pool Trunks in Lync Control Panel.  Go to Voice Routing - Trunk Configuration.  Click New - Pool Trunk for each PSTN gateway.  Make sure the name of the pool trunk is the same as the PSTN Gateway.  Once complete, you should have something similar to this:

Now, go to the Dialing Rule Optimizer at http://www.LyncOptimizer.com.  I originally created this tool to help create optimized local dialing rules for AudioCodes and Dialogic gateways.  I've recently added Lync functionality.  You will be presented with the following screen:

Enter the area code (NPA) and exchange (NXX) for each of your sites. Leave the gateway type as Lync 2010.  If your PSTN gateway requires a 9 or other number to be dialed before the actual phone number, enter it at External Access #.  Enter the PSTN gateway name in the same format as you created in Topology Builder. In our example, we'll use miami.root.loc. Enter your email address so you will be notified when dialing rule changes are detected.

If your local dialling area allows 7-digit dialling and the 7-digit dialing area spans more than one area code, select the 7-Digit Normalization option.  The program will create 7-digit normalization rules that correspond to your local dialing area.  For example, Kansas City, MO allows 7-digit dialling across the 816 and 913 area codes. With 7-digit normalization selected, the Dialing Rule Optimizer will ensure that user-dialled 7-digit numbers are normalized to E.164 format for the correct area code.  For example: if a user dials 2915555, Lync will normalize the number to +18162915555.  If they dial 2195555, Lync will normalize it to +19132195555.

ONLY USE THE 7-DIGIT NORMALIZATION OPTION IF 7-DIGIT DIALLING IS ALLOWED IN YOUR AREA. If you generate 7-digit normalization rules for an area that does not allow 7-digit dialling, you will likely see inconsistent results.

Once done, press Generate Rules.  After a short while, you will see a link to a text file that contains all the Powershell commands required to setup Least Cost Routing for that particular site.  Copy the contents of the text file into the Lync Powershell dialog box.  The rest should be taken care of! 

Here's a sample of what the Powershell commands look like for 305-836 (Miami) with a PSTN gateway name of miami.root.loc:
Set-CsPSTNUsage –Identity global –Usage @{Add='NA-FL-Miami-Local'}

New-CSVoiceRoute -Name 'NA-FL-Miami-1' -Description 'Least cost routing for Miami, FL' -PSTNUsages 'NA-FL-Miami-Local' -PSTNGatewayList 'miami.root.loc' -NumberPattern '(\+1561((21[0238])|(2(06|08|37|39|41|45|87|88|89))|(36[1278])|(39[12345])|(3(00|02|05|72|78))|(44[2357])|(45[1678])|(4(16|17|70|77|79))|(5(04|05|44|49))|(67[24])|(75[06])|(86[2469])|(8(83|86|92|93))|(98[1289])|(99[145789])|(9(10|12|22|23|29|53|55|61|62))|((226|297|314|322|338|347|353|400|435|520|558|613|620|636|705|773|807|826|852|939|948))|(48)))|(\+1754(([234578])))|(\+1954(([23456789])))|(\+1786(([23456789])))|(\+1305(([23456789])))'

New-CSOutboundTranslationRule -Parent 'PstnGateway:miami.root.loc' -Name 'NA-FL-Miami-1-Local' -Description 'Removes +1 for local calls to Miami, FL' -Pattern '\+1((561((21[0238])|(2(06|08|37|39|41|45|87|88|89))|(36[1278])|(39[12345])|(3(00|02|05|72|78))|(44[2357])|(45[1678])|(4(16|17|70|77|79))|(5(04|05|44|49))|(67[24])|(75[06])|(86[2469])|(8(83|86|92|93))|(98[1289])|(99[145789])|(9(10|12|22|23|29|53|55|61|62))|((226|297|314|322|338|347|353|400|435|520|558|613|620|636|705|773|807|826|852|939|948))|(48)))|(754(([234578])))|(954(([23456789])))|(786(([23456789])))|(305(([23456789]))))' -Translation '$1'

Repeat for each gateway in your environment.  To check the results, use Lync Control Panel. Under Voice Routing - Route, you should see something like the following:

Auto-created routes are formatted like this NA-state-city-#.  For example, NA-TX-Dallas-1. If the route length is longer than 1024 characters (like Dallas), it has to be split into multiple routes, hence NA-TX-Dallas-2.

PSTN Usages should contain a PSTN Usage for each site, named like NA-state-city-Local
.  For example, NA-TX-Dallas-Local.  The PSTN Usage will contain all the routes for that particular city.

Finally, each PSTN gateway defined in Trunk Configuration should have at least one trunk normalization rule.  This rule will strip the +1 from the phone number before sending it to the PSTN gateway.

Drilling down into one of the trunks shows the translation rules for that particular trunk.

If you've selected the option to create 7-digit normalization rules, these rules will be placed in the Global dial plan in the format NA-state-city- Local Calls.  You should copy the rules to the appropriate dial plan.

One final step that's required to pull it all together is to assign the auto-created PSTN Usages to the appropriate Voice Policy.  Edit the voice policy/policies you want the Least Cost Routing to apply to, and add the PSTN Usages to those policies.  Commit the changes and you're done!

Now, when your users dial any number that is local to a defined city, the call will be routed out the appropriate PSTN gateway.  As long as you entered your email address, incorporating changes is as simple as re-applying the updated rules that are emailed to you to your Lync deployment. 

This post shows you how easy it is to configure Lync Server 2010 for Least Cost Routing.  Comments are always appreciated!

For more background on the Dialing Rule Optimizer, see this post.

Wednesday, October 13, 2010

Cross-Firewall File Transfer in Lync

In my "lab" environment, I'm running Lync Server 2010 RC in an existing OCS 2007 R2 corporate environment.  Since I didn't want to do anything that would impact the existing user population, I didn't make any unnecessary changes to the existing edge server environment.  So, I'm using our existing OCS 2007 R2 edge server to communicate with my Lync 2010 front-end. 

Since its not a full Lync 2010 environment from end to end, I expected certain Lync 2010 features would simply not work.  One of those long awaited features is the ability to transfer files between users who are on different firewalled networks.

In OCS 2007 R2 and older versions, people were often frustrated by the inability for Communicator to transfer files between users who were not on the same network.  File transfers worked peer-to-peer, and if the clients couldn't reach each other directly via their local IP address, then the file transfer would fail with a message like this:
You cannot receive the file ChuckNorrisFacts.doc from Chuck Norris.  This may be due to firewall restrictions or network problems. If you need further assistance, please contact your system administrator.
In Lync 2010, file transfers between users on disparate networks will work, because Lync 2010 is a lot smarter about finding a routable network path to the other party.  Lync will use ICE (Interactive Connectivity Establishment) and SDP (Session Description Protocol) to find a media path to send file data in much the same way that Communicator used ICE/SDP for voice/video traffic.  For an excellent description on how Communicator uses ICE/SDP, read this post by the Communications Server team.

I had assumed you would need to use the Lync client in conjunction with a Lync edge server for file transfer to work properly.  To my surprise, I found that a Lync edge server is NOT a required component.  The Lync client does all the ICE/SDP work to find a routable media path.  When either party is behind a firewall and can't be reached directly from the other user, Lync will use the existing OCS/Lync edge server to act as a proxy. 

I confirmed this by reviewing the Lync client logs on my machine.  By the way, its very handy to turn on logging in Lync.  It can be very useful when troubleshooting, or in this case, just trying to figure out how things are working.  Digging through the Communicator-uccaip-0.uccapilog file in my Tracing folder (they still haven't updated the names of the log files for Lync), I could see the following IP candidates offered by the other client just prior to the transfer:
a=candidate:1 1 TCP-PASS 2120613887 10.1.1.71 29884 typ host
a=candidate:1 2 TCP-PASS 2120613374 10.1.1.71 29884 typ host
a=candidate:2 1 TCP-ACT 2121006591 10.1.1.71 19511 typ host
a=candidate:2 2 TCP-ACT 2121006078 10.1.1.71 19511 typ host
a=candidate:3 1 TCP-PASS 6556159 209.2.2.23 57733 typ relay raddr 10.1.1.71 rport 22533
a=candidate:3 2 TCP-PASS 6556158 209.2.2.23 57733 typ relay raddr 10.1.1.71 rport 22533
a=candidate:4 1 TCP-ACT 7076607 209.2.2.23 57733 typ relay raddr 10.1.1.71 rport 22533
a=candidate:4 2 TCP-ACT 7076094 209.2.2.23 57733 typ relay raddr 10.1.1.71 rport 22533
I won't go into the details of each of these candidate lines because the Communications Server Team does such a great job explaining it, but the 10.1.1.71 address is the internal address of the other user, while the 209.2.2.23 address is the external AV edge IP address of my OCS 2007 R2 edge server.  You can see that several of the candidates are offering to use the AV edge IP address to relay the file transfer data from the other user's internal IP address.

So, to make a long story short, it appears that you won't have to wait to have a fully deployed Lync Server 2010 infrastructure to start taking advantage of the vastly improved file-transfer abilities in the Lync client.

Tuesday, October 5, 2010

Who says Microsoft doesn't have a sense of humour?

You know the default silhouette placeholder that Outlook 2010 and Lync 2010 shows you by default when there isn't a user picture?  You won't believe the story behind that...

http://arstechnica.com/microsoft/news/2010/09/bill-gates-staring-back-at-you-from-outlook-2010.ars

Monday, October 4, 2010

Dialing Rule Optimizer and your Email Address

If you've used the Dialing Rule Optimizer to create localized dialing rules for your Audiocodes/Dialogic gateway or OCS/Lync, you may have noticed the option to enter your email address. The ONLY reason I use your email address is to automatically notify you when there have been changes in the dialing rules.  I will never sell or give your email address to anyone. 

As of right now, I do a monthly check for all those people who have entered their email address on the first of the month, and the program automatically sends them the updated rules.  For instance, this month I sent out updated rulesets to almost half of all the users who entered their email address.

Surprisingly, the local calling area for a given telephone exchange is updated on a pretty frequent basis, which means that your dialing rules could be out of date.  Your users might not be able to complete calls to newly added telephone exchanges. 

Allowing me to contact you via email is also handy for when I make changes in the logic to improve the rule generation process or to fix an error that may result in an incomplete ruleset.

On another note, if you ever find an error or inconsistency in the ruleset, PLEASE let me know so I can investigate.  Based on the lack of feedback so far, I can either assume that the program is working perfectly (which I'd like to think is the case), people are not validating the results, or they are simply tossing it out and not using it at all.

So, check out and use the Dialing Rule Optimizer, and enter your email address so you can stay up-to-date, and send me a note to give me some feedback  :)

Ken

Friday, October 1, 2010

Check your Exchange 2010 UM Dial Plans Before Upgrading to SP1

I thought I'd pass along my experience with some undocumented UM changes in Exchange 2010 SP1 that recently caused a client some grief. 

This particular client has made extensive use of UM dial plans and auto attendants, with it all tied in to a Cisco Call Manager telephony environment.  The way they configured their AAs wasn't done in a manner recommended by Microsoft.  Specifically, they didn't consistently assign Dialing Rule Groups to their AAs. 

If you're not familiar with Dialing Rule Groups, they are essentially groupings of dialing rules used to determine the types of calls that users can make when they make outgoing calls via Exchange UM.  For instance, you might have a dialing rule group that contains a set of rules that only allows local calls.  According to MS Best Practices, every dial plan and auto attendant should have at least one dialing rule group assigned to handle every possible combination of numbers it is expected to see.

The UM Dial Plans used by this client were almost exclusively set to 4 digits.  Many of the AAs had key mappings (ie Press 1 to reach Sales) that routed to 7-digit extensions.  There were no dialing rule groups in place on the AAs.  In Exchange 2007 and Exchange 2010 RTM, this didn't seem to matter.  The auto attendants always routed the calls properly.

However, once we put in SP1, all the auto attendants that routed calls to extensions with more than 4 digits failed.  Users would get to the main menu, press the button corresponding to the key mapping and get a message saying the call could not be completed, and the caller was returned to the main menu. 

After much sweating, hand-wringing and a call to MS Premier Support, we determined that we required a dialing rule group on each of the auto attendants that routed to 7-digit extensions.  Once done, calls were routed as before.

The Microsoft support rep said that the AAs should never have worked using the configuration this client had in place.  However, this client had successfully used this method in both Exchange 2007 and Exchange 2010 RTM.  It was only Exchange 2010 SP1 where this became an issue.  One way you could look at it is that Exchange 2010 SP1 corrected an logical oversight in previous versions.

So, in essense, make sure your dial plans and auto attendants are configured according to Microsoft's Best Practices BEFORE upgrading to Exchange 2010 SP1.

Wednesday, September 29, 2010

E2K7 OWA Redirect Bug Introduced with Exchange 2010 SP1

I just deployed Exchange 2010 SP1 to an enterprise customer that has a mix of Exchange 2007 and Exchange 2010 users.  It seems that SP1 has introduced a rather aggravating and obvious bug.  Before I get into that, I'll give some background on how Exchange 2010 coexists with previous versions of Exchange.

When you have a mix of Exchange 2010 and older versions in your environment, you have to do a bit of work to make the two work together for your external users.  In a nutshell, you use Exchange 2010 Client Access Server (CAS) as your primary entry point for all external users. 

Say you use owa.company.com as your externally accessible URL.  If an Exchange 2010 user logs in from the Internet, the Exchange 2010 CAS will do its thing and the user will get a nice Outlook Web App screen.

If an Exchange 2007 user logs in using owa.company.com, the Exchange 2010 CAS will redirect the user to an externally accessible Exchange 2007 CAS using a different URL (like legacy.company.com).  The redirection is silent, but the user may notice their browser changed to legacy.company.com

How the redirect is handled is managed by the LegacyRedirectType setting in the Exchange 2010 OWA virtual directory.  In most cases, LegacyRedirectType is set to Silent.  To see what the setting is in your environment, run:
Get-OWAVirtualDirectory -Server <CASservername> | FL Identity, LegacyRedirectType
In SP1, this redirection is no longer silent.  When your Exchange 2007 user logs in via owa.company.com, they are presented with this screen:

The text reads:
A temporary change has occurred that requires you to connect to a different server.  To connect, click the button below.  For security reasons, you'll be asked to enter your user name and password again.
Sure enough, when you click Connect, you are redirected to legacy.company.com, where you have to re-enter your user information.

Thankfully, the same sort of thing doesn't seem to happen with Outlook Anywhere or ActiveSync clients.

I checked the LegacyRedirectType value on my 2010 SP1 CAS boxes and they are all still set to Silent.  I've read the issue occurs because the OWA virtual directory value for LegacyRedirectType is being ignored.  Apparently, this bug was to be addressed in Exchange 2010 SP1 RU1, but that wasn't the case.  Hopefully, Rollup 2 will fix the issue.

This is an extraordinarily unfortunate thing to have been introduced with SP1.   If you have a mixed Exchange 2007/2010 environment, I suggest you wait before deploying SP1.

UPDATE (01-Dec-2010):  Thanks to an anonymous commenter below, there is a workaround for the OWA redirect issue.  Navigate to C:\Program Files\Microsoft\Exchange\v14\ClientAccess\Owa (or whereever you installed Exchange) and edit the casredirect.aspx with Notepad.

Add the following line just under the existing meta-tag that starts with <meta http-equiv...:
<meta http-equiv="refresh" content="0;URL=https://legacy.domain.com/owa">
Replace legacy.domain.com with whatever you are using for your redirect URL.  Save the file and issue an IISRESET from the command line.  When your legacy users logon to OWA, they will still see the redirect page, but users will not have to press the button to continue.  It should automatically switch them to the legacy URL. 

It's not perfect, but at least its something.  Thanks again to the anonomous user who brought this to my attention!

FINAL UPDATE (14-Dec-2010): The redirect issue has finally been fixed in Exchange 2010 SP1 Rollup 2!  Read more about it here.

Friday, September 24, 2010

New September 2010 Hotfixes For OCS R2 Response Group Issue

Microsoft has released a new set of hotfixes to fix the Response Group problems introduced with the July 2010 set of hotfixes.  There are 4 required updates for the following services:
  • Response Group
  • Core Components
  • Web Components
  • Administration Tools
Get a direct link to the server hotfix installer here, which will install all the required updates.

Wednesday, September 22, 2010

Lync Click-to-Call in Internet Explorer

In the olden days before Lync, if you wanted to use Communicator to dial a phone number from a webpage, you had to follow a multi-step process: 
  1. Select the phone number
  2. Copy the phone number using Control-C or right mouse click and select Copy
  3. Bring up Communicator
  4. Click on the phone dialing window
  5. Control-V or right mouse click and select Paste.
  6. Click Dial.
Man, I'm tired just from reading that!  A feature that I've been waiting for a long time has finally made its way into Lync 2010: click-to-call from within Internet Explorer.  This has been an oft-asked for feature by several clients.  This feature was available in the past via some 3rd party add-ons, with limited success.  It's nice to see it in the base Lync client product.

When you install Lync, it will also install two IE add-ons:  Lync Browser Helper and Lync add-on, which you can see by clicking on Manage Add-ons from the IE Tools menu.  There are no configurable options.

Also from the Tools menu, you will see an option for Lync add on, which gives you a few simple options (enabled by default).

On every IE webpage you visit, Lync will determine what is a phone number using some internal normalization rules (non-viewable or editable at this time).  When a match occurs, Lync 2010 will place a small icon beside the number like this:

When you hover over the icon in a webpage, you'll see something like the following:
I've found that Lync is fairly good at determining what is a phone number and what isn't. Oddly, it doesn't seem to accept E.164 formatted phone numbers (ie. +15195551111), unless there's a space in it. Other add-ons I've tried would treat pretty much any string of numbers as a dialable number, which was irritating. 

Clicking the icon will bring up a Lync call window and Lync will automatically dial the number.
Instead of six steps, you can dial with just one click of the mouse.  An extremely useful and handy feature!

Wednesday, September 15, 2010

Lync 2010 and Multiple Locations with Same IP Subnet

One question users keep asking me about the Location Services in Lync 2010 is "What happens if I have the same IP addressing scheme at multiple locations?"

In my previous two posts, I talked about how Lync 2010 will keep track of the locations you've setup and will automatically set your location properly when you return.  So, what DOES happen when you leave the office, which gave you an IP address in the 192.168.20.0/24 subnet and you go home where you just so happen to use the exact same subnet? Will Lync 2010 just look at the subnet and assume that you're still in the office?

It turns out that Lync 2010 will gather as much information about your connection as it can when determining your actual location.  Not only will it use your IP address, but it will also use the identifier of the wireless access point you've connected to, or the switch ID, if connected via a hardline.

I tested this at home by connecting to two different wireless access points.  I first connected to my primary WAP and logged onto Lync 2010.  I dutifully entered my location information and set it as "Home".  I noted my IP address and disconnected.  I reconnected to my backup WAP and logged onto Lync 2010.  I had the same IP address as before.  Lo and behold, Lync asked me for my location information as if it were a new location.  I entered the same information as before, but with the location tag of "Home Test".

I then reconnected to my original WAP and sure enough, the location was set back to "Home".  I reconnected to the backup WAP, and my location changed to "Home Test".  The IP address remained the same on both WAPs, but Lync was obviously looking at more than just the IP address when determining my location.

So, Lync 2010 turns out to be very intelligent about how it determines your actual location.  It will use a combination of your IP address and any other information it can glean from the connection to ensure uniqueness.  Once you've been to most of your usual locations and set your location information once (even if those locations are not in your corporate network, you shouldn't have to ever manually set it again.

UPDATE: Jens Trier Rasmussen's blog provides some more detailed information about what exactly is used to uniquely determine your location:  http://blogs.technet.com/b/jenstr/archive/2010/09/17/how-can-lync-2010-distinguish-between-network-192-168-1-x-at-home-and-in-hotel-x.aspx

Tuesday, September 14, 2010

Configuring Location Services in Lync Server 2010 - Part 2

In my last post, I talked about how to configure Lync Server 2010 to allow users to enter their detailed location in Lync 2010 for use during a call to E.911 emergency services.  Today, I will talk about how to create and manage a central location database, and how to link the location information with your users.

Giving users the ability to manually input their location is important, especially when they are outside the office. However, when inside your corporate network, requiring all your users to input their specific location is an unnecessary burden, not to mention the inevitable errors that can delay emergency services.  Lync Server 2010 allows administrators to create a database of locations that map to your internal network topology. 

Location information can be set as high level as an entire internal network subnet, or can be as granular as individual switch ports.  Lync Server 2010 allows you to link locations to the following:
  • IP subnet via Set-CSLISSubnet
  • Wireless access point (basic service set identifier (BSSID)) via Set-CSLISWirelessAccessPoint
  • Switch (either MAC or IP address) via Set-CSLISSwitch
  • Switch port (switch MAC or IP address and port ID) via Set-CSLISPort
When you create a location database entry using the above Powershell commands, you can also enter all the location-specific information you have available. Hopefully, you have all the information you need in a CSV file that you can manipulate and import, saving you the tedium of manual entry. One thing to note is to make sure you DON'T publish any VPN subnets in your database. Since users who VPN in could be physically anywhere, you don't want to have their location be set to the office when they're really at home.  When a user is at home, they will have to enter their location information manually, as described in yesterday's post.

Once you've populated the location information database, you should validate it against the Master Street Address Guide (MSAG) maintained by your E911 call routing provider.  Microsoft has partnered with a few E911 routing providers in the US: 911 Enable and Intrado, with more to follow.  I understand that there will also be some E911 routing providers in Canada at some point as well.  If you don't have a E911 provider, you can skip these steps and continue on to publishing.

You setup your connection to your E911 provider using the following command:
$pwd = Read-Host –AsSecureString <password>
Set-CsLisServiceProvider -ServiceProviderName <Name> -ValidationServiceUrl <ProviderURL> -CertFileName <ProviderCert> -Password $pwd
Once setup, you can validate your addresses via the following command:
Get-CsLisCivicAddress | Test-CsLisCivicAddress –UpdateValidationStatus
You can also test addresses individually using Test-CSLisCivicAddress by itself.

Once you've validated your addresses (assuming you have a E911 provider), you have to publish the database:
Publish-CSLisConfiguration
If you successfully validated your addresses, your users' location will be automatically set when they are in a supported location (and can't be changed). 

If you are outside the US and can't validate your addresses against a MSAG provider, your users will see the following when they click on Set your Location:

The Suggested Location is populated from the Location Database information.  When a user selects the Suggested Location, they are brought to the same location information entry screen as when the user is outside a corporate network, except the address information is already populated. 
 
The user just has to type in a Location Name that is shown to other users.  The next time the user is at this location, the location will be automatically set.

For the location to be auto-populated, the civic addresses entered have to be validated against a MSAG.  If you're outside the USA, you won't be able to do this. 

An UNSUPPORTED way to gain the same auto-location setting capabilities for non-US installations is to directly edit the dbo.CivicAddresses table in your LIS database using SQL Management Tools and change the MSAGValid field from False to True on all your civic addresses.  If you're running Lync Standard Edition, install the SQL Server 2008 R2 Express Management Tools, or use SQL Management Tools from another SQL server. Keep in mind that this is UNSUPPORTED, and I can't be liable for any issues that arise. If you're unfamiliar with SQL, its best to leave things alone.

UPDATE:  The January 2011 Rollup 1 for Lync 2010 includes an update that removes the requirement for addresses to be validated against a MSAG. 

This post is meant as a basic overview of how to enable location services in Lync Server 2010.  If you want more detailed information on specific aspects of how to perform location or E911 tasks, please refer to the help documents contained with the Lync Server 2010 RC eval.

Monday, September 13, 2010

Configuring Location Services in Lync Server 2010 - Part 1

What is Lync Server 2010, you may ask?  If you haven't seen it mentioned anywhere else yet, then I guess I'm the first to let you know that CS "14" is now officially known as Microsoft Lync Server 2010.  The client is simply known as Lync 2010.  I'm not all that crazy about the name yet, but hopefully it will grow on me. If you want to try it out, the release candidate is now publically available from here.  You really should put it in a lab, but I've been running it in a limited production environment for several months now with very few issues. Its a very solid product. Now on to our regularly scheduled posting....

One important feature added to Lync Server 2010 is support for E.911.  E.911 (or Enhanced 911) is the next-generation of 911 emergency services in North America.  It provides location information for non-landline-based telephone numbers, like mobile phones and IP phones. 

The three most important things to note about E.911 is the same three things you need to worry about with real estate:  location, location, location.  Due to the inherent mobility of Lync users, it is critical that the telephony solution provide some manner of ensuring users can be automatically located in the event of a 911 emergency call. 

Lync Server 2010 provides several ways to ensure locatability (is that a word?).  The simplest method is to allow or force users to enter their location information at login to Lync.  By default, this feature is turned off in Lync Server 2010 RC, but you can enable it by typing the following command:
Set-CSLocationPolicy -Identity Global -EnhancedEmergencyServicesEnabled:$TRUE -LocationRequired:Yes
The default Location Policy is called Global, but you can create new site-level or user-level location policies if required by your deployment.

EnhancedEmergencyServicesEnabled enables the location features in Lync Server 2010. This must be set to $TRUE for anything else to work.

LocationRequired can be set to No (Don't prompt for location), Yes (prompt for location, but allow user to ignore) and Disclaimer (prompt for location and don't allow user to ignore).  If LocationRequired is set to Yes, users will see Set Your Location when they log into Lync for the first time at an unrecognized location:

If LocationRequired is set to Disclaimer, users will see the following:

If they dismiss the prompt, a message like this will pop-up:
The message can be changed by using the command Set-CsEnhancedEmergencyServiceDisclaimer.  The current documentation says that when using the Disclaimer option, users will not be able to make non-emergency calls if they ignore the prompt, but in the Release Candidate I was still able to make calls. 

When they type in a location name such as Home, a dialog box will pop up with additional address information:

To make this information available to emergency services, you have to make a few more modifications to the location policy using Set-CSLocationPolicy:
Set-CSLocationPolicy Global -EmergencyDialString "911" - EmergencyDialMask "112" -PSTNUsage "Emergency"
EmergencyDialString is the number that will be treated as being an emergency call. The call SIP data will include the user's location. This is 911 in North America.

EmergencyDialMask is an alternate number that will be converted to EmergencyDialString for the location profile. In this case, 112 (emergency dial number for many countries) would be converted to 911 and treated as an emergency call.

PSTNUsage is the Phone Usage that will be used to route the emergency call. In this example, I used "Emergency", which is a Phone Usage I created that contains a route for 911 calls. 

With this enabled, your users will be able to input their own specific location information so that emergency services can easily find them if they call 911.  The nice thing about it is that if a user goes to several locations and properly enters their address information, Lync will recognize those locations and will select it automatically the next time they are at that location. 

However, since this particular solution depends on users inputting their location information correctly, it isn't ideal for a corporate setting.  My next blog posting will detail how administrators can assign locations to users based on information stored in a central database.

Until then,
Cheers!
Ken

Thursday, September 9, 2010

First Impressions - CS14 Release Candidate

I installed the release candidate of CS14 in my "lab" yesterday.  My "lab" is a single Standard Edition server in our production OCS R2 environment with a few hardy volunteers to try it out.  This release is very polished, and has several little UI improvements that go a long way to make it easier to do common things.

Everything worked just as it should with little fuss.  One thing I absolutely love is the new web client.  Its a very slick Silverlight-based app and is leaps and bounds beyond Live Meeting in terms of usability.  Now, any browser than can run Silverlight can participate in web conferences.  The web client is built in to the base front-end server install so no more dedicated CWA server required.  I've already shown this to several clients and they can't wait to put it in.

The only thing that I didn't see (and I put in a request for) was the ability to test Enterprise Telephony routes from end-to-end.  The test cases you can enter allow you to test normalization rules and routes to make sure everything routes as expected.  However, it doesn't show the effects of any trunk-level translation rules you might be using. 

For instance, my Dialing Rule Optimizer website provides end-to-end routing and trunk translation rules that will route and convert E.164 phone numbers to numbers that conform to the local PSTN dialing requirements for a given area (ie. Don't use 1 for local calls).  Ideally, the Test Cases would show you the number it will send to the next hop gateway, but it doesn't.  It shows you the normalized number and the route it will take, but it doesn't show you the effects of any trunk translation rules.  You have to look at your gateway logs to find out.  To me, this seems like a very simple addition to an otherwise very useful tool.  With any luck, it might make it into the final release if this post finds its way to the right people.

Tuesday, September 7, 2010

OCS R2 PBX Integration Mode User Experience

If you're familiar with OCS R2, you've probably come across the checkbox under Telephony options called "Enable PBX Integration".  You would enable this setting when you want to set someone up for Enterprise Voice, but still want the user to be able to use a deskphone.  All calls are forked to both OCS and PBX endpoints, and you can also use Communicator to control your deskphone (Remote Call Control - RCC).  This might sound like you would get the best of both worlds, combining the rich featureset of Enterprise Voice and the ability to use Communicator to control your deskphone....a wonderful union of old world and new world technology.  However, the reality is quite different. 

At first glance, it would seem that enabling a user for both Enterprise Voice (EV) and Remote Call Control/PBX Integration (RCC) would combine the best features of EV and RCC. However, in practice, this is not the case. Most EV features are not available in PBX Integration mode, as noted in the table below:

Visually, the differences between the two options are shown below. With Enterprise Voice, you can see the wealth of call control options available to a user. With PBX integration, the options are limited to the same set available with RCC only.

Again, below are the detailed call forwarding options available to Enterprise Voice users (left) and PBX Integration users (right). PBX Integration users are limited to the features available on their desk phone, while EV users have a wide range of options available.

As you can see, enabling a user for both EV and RCC reduces the featureset available to users to essentially the same as simple RCC but with the addition of using your computer as phone.  I've found that presenting the results as above usually makes decision makers change their mind about allowing their users the use of both their old deskphone and Communicator Enterprise Voice.  Ultimately, the best user experience is to use Enterprise Voice exclusively.