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.

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.

Warning about OCS R2 RGS and July 2010 Updates

If you've applied the July 2010 cumulative updates to your OCS R2 environment and you use the Response Group Service, you'll want to take note of this update from Microsoft:  http://support.microsoft.com/default.aspx?scid=kb;en-us;2401878&sd=rss&spid=14030

In a nutshell, if you make any changes to a response group or create a new one, calls to the affected response group could fail unless you restart the service.  This issue will be fixed in the September 2010 cumulative update package.

Thanks to RPasztor for bringing this to my attention.

Dialing Rule Optimizer for E.164 Phone Numbers

A few years ago, after realizing the importance of E.164 in formatting phone numbers in OCS, I came across a problem.  Our company is in the Toronto area, and the local telephone carrier doesn't accept E.164 formatted phone numbers.  Sure, it requires that you dial a 1 for a long distance phone number, but if you dial a 1 for a local number, the carrier rejects the call with the helpful "This is a local number.  Please do not dial 1" or something to that effect.  To get around this issue, I had formatted any local numbers we stored in Active Directory without the 1, so our users could click to dial without any issue.  This worked fine for our users since we had a single mediation server. 

However, companies we were federated with couldn't dial the phone numbers, because they were not formatted in E.164.  For instance, while setting a user's telephone number in AD as +9052221111 worked fine for other users in our company, when a federated contact tried to use click to dial that number, they would either get a fast busy or would find themselves talking to someone in Turkey (who has the country code 90). 

I could see the requirement for using E.164 phone numbers in Active Directory, but I couldn't see a way to get around the carrier limitation of not using a 1 for local calls.  Since OCS R2 didn't have any way to manipulate numbers before sending to the PSTN, a media gateway would be required to do the necessary manipulation.  We were using an AudioCodes media gateway for our connection to the PSTN, and I knew I could define rules that would strip the 1 when required.  A website called Local Calling Guide had a list of all the local prefixes for a given phone number, but since there were 1380 local prefixes for our company's phone number, I didn't see a way of importing these rules into our gateway (the Audiocodes has a 125 rule limit, I hear), let alone manage any changes.

I was resigned to the fact that we wouldn't be able to use true E.164 dialing in our environment and would have to accept the downsides.  I had numerous discussions with Clive from Microsoft on this topic.  Clive went ahead and created a spreadsheet where you would copy the local dialing rules into one page, and with some Excel trickery and a lot of manual labour, came up with a somewhat optimized ruleset that could be imported into the AudioCodes gateway.  It worked like a charm, however, the amount of manual work involved meant there was lots of room for error, and it would be pretty much impossible to detect changes to the ruleset over time.  Not only that, modifiying the spreadsheet to work with other gateways such as Dialogic would be problematic at best.

Clive's Excel-based solution got me thinking about a better way to create optimized rules for AudioCodes and Dialogic gateways.  After many, many late nights of programming (and I'm not a programmer!), I came up with a VBScript-based HTA program that did a good job of creating an optimized ruleset for any type of gateway I could get my hands on.  Later iterations further optimized the logic to the point where the 1380 individual rules for our company's local number got optimized down to 47 rules! 

An old HTA version of the Optimizer

I later converted the HTA to a full-fledged website and made it available to anyone who needs optimized dialing rules for an AudioCodes or Dialogic gateway.  I also included OCS dialing rules that could be imported into the Enterprise Voice Route Helper to help create least-cost routing rules.  If you enter your email address, the webpage will email you with updated rules, if changes are detected (or further optimizations are done). 

The latest version

Recently, I updated the website to include PowerShell commands to import into Lync deployments. Lync now allows manipulation of phone numbers before passing it to the next hop gateway, which makes it easier to manage from a central location.  You can now simply copy-and-paste the output from the Optimizer directly into Lync PowerShell to automatically create phone usages, routes and gateway translation rules. 

Please try it out, and give me any feedback you can!

http://www.LyncOptimizer.com

Normalizing Outlook Contact Phone Numbers to E.164 Format

When setting up OCS for Enterprise Voice, it's important to format your Active Directory users' telephone numbers to the E.164 international format, which is +<CountryCode><Area/CityCode><LocalNumber> (see this post by Doug Lawty of Microsoft for more information on why E.164 formatting is important for Enterprise Voice).  For instance, North America's country code is 1, area codes are 3 digits and local numbers are 7 digits, so we get something like +14165551111. 

Ideally, your personal Outlook contacts should also be formatted to the E.164 standard as well.  Outlook 2010 does a better job than previous versions to encourage proper formatting when creating a new contact, but many people will have a lot of legacy contacts that are likely all over the place in terms of formatting.  You can use OCS normalization rules to help deal with getting Outlook contacts to format properly in OCS, but I think its a better idea to fix the source data if at all possible.

Telling your users to manually fix up all their contacts could result in mobs of angry users with pitchforks knocking down your door.  More likely, they just simply won't bother.  To make it easier on users, I've created a VBScript stuffed inside an Exchange Organizational Form that will do the trick nicely.

Create a new blank Organizational Form with instructions on what the form does and a big, fat button on it called NormalizeNumbers (see below for an example).

Click on the View Code button, and paste in this code.  Save it and publish the form.  If all goes well, users should be able to click the button and all the contacts in their default Contacts folder should be updated to E.164 format.  Just in case, they should backup their contacts to another folder.  As always, the code provided is to be used at your own risk.

Good luck!
Ken