Dial-in Conferencing in Lync - A Foot in the Door

Office Communications Server 2007 R2 was the first version of OCS to offer PSTN (or dial-in) conferencing as part of the base product offering.  It provided a relatively well-rounded set of features, especially when the presenter ran the dial-in conference from the Communicator client.  Booking audio conferences was a breeze when coupled with the Outlook Conferencing Add-In.  Presenters could easily see who was in the conference and could mute unruly participants with the click of a mouse.  However, the presenter experience was lacking when dialed in from a regular phone.  There was no way to perform any of the usual functions via a touch-tone phone like roll calls or global mute, which limited its appeal in circumstances where Communicator wasn't a viable solution for running a dial-in conference.

Like it or not, but many companies have yet to jump on board the OCS bandwagon for a multitude of reasons.  A side result of this is that many users simply do not have the headsets or other hardware necessary for a good computer-based telephony experience.  Since their only real choice for hosting conferences is via a regular telephone, the lack of in-conference features in OCS R2 limited its appeal to companies who either were already using Enterprise Voice, or ones who took the time to invest in headsets so their users could host their audio conferences from Communicator.  This leaves a lot of companies with one less compelling reason to deploy OCS.

Dial-in conferencing in Lync will become a significant driver for companies to make that initial foray into Microsoft's Unified Communications world.  The biggest reason is that the PSTN conferencing featureset has improved to the point that it can be a viable replacement for many corporation's existing hosted PSTN conferencing services.  Presenters who dial in via telephone can use the keypad to perform almost all the features normally available via hosted teleconferences, which eliminates one of the key blockers for adoption. 

Coupled with a direct connection to an external SIP provider such as Thinktel in Canada, companies can easily host their own dial-in conferences at a fraction of the cost of traditional hosted teleconferencing solutions.  If a company is already deploying Lync for IM and internal conferencing, it's very easy to add the dial-in conferencing functionality, since the mediation server can be colocated on front-end servers and a direct SIP connection doesn't interfere with the company's existing PBX. 

With this "foot in the door", companies can get a real feel for the stablility, ease-of-use and cost-effectiveness of Lync.  Over time, companies may be more open to moving their main telephony solution to Lync and can start to take advantage of the entire featureset available.

Migrating Exchange 2007 UC Custom Prompts to 2010 SP1

If you've migrated from Exchange 2007 to Exchange 2010, you may have experienced some frustration at Microsoft's documentation on how to migrate UC custom prompts (customized audio files for UM autoattendants etc) to Exchange 2010.  A bit of background:  When you recorded a custom greeting for an Exchange 2007 autoattendant or dialplan, the audio file got copied to a fileshare known as the prompt publishing point, a folder that stored all the audio files for a given dialplan.  The Exchange File Distribution Service would copy the audio files to other UM servers in the dialplan.  In Exchange 2010, the audio files are now stored in a system mailbox.  Since there is no automatic synchronization of custom prompts between Exchange 2007 and 2010, some migration process is necessary to copy the 2007 custom prompts to 2010.

A Technet article helpfully explained how to migrate individual custom prompts, but the process was far too tedious to migrate any more than a handful.  I created a simple Powershell script that did the job fairly nicely for a client with several hundred custom prompts, but it still involved multiple steps and had to be run directly on each UM publishing point.  I was going to publish the details here, but I don't need to do that now.

Thankfully, with the release of Exchange 2010 SP1, there is now a very simple way to migrate ALL your custom prompts with a single Powershell script provided by Microsoft: MigrateUMCustomPrompts.ps1.  You can find the script in the Scripts folder on any Exchange 2010 SP1 server installation (or even on the DVD).  Just run the script without any switches and it will copy all custom prompts from all publishing points into Exchange 2010.

A VERY helpful script that hasn't seen much publicity yet.

Can't log on to migrated mailbox

I'm working at a client, migrating from Exchange 2007 to 2010.  We're well into the mailbox migration portion of the project and it's been going very well.  However, today after migrating a bunch of service account mailboxes, users who had access to one of the mailboxes couldn't log on to it via Outlook anymore.  They kept getting the error message:

Cannot display the folder. Microsoft Exchange is not available. Either there are network problems or the Exchange computer is down for maintenance.

I tried accessing the same mailbox from both inside and outside the network and got the same error.  Even creating a new Outlook profile didn't help.  However, OWA worked fine.

After doing some digging, I saw this interesting error message on one of the 2010 CAS servers whenever I tried to access the problem mailbox:

Unhandled Exception "Multiple objects with legacy DN /o=COMPANYNAME/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=investors were found."
Stack trace: at Microsoft.Exchange.Data.Directory.Recipient.ADRecipientSession.FindByLegacyExchangeDN(String legacyExchangeDN)
at Microsoft.Exchange.Autodiscover.Providers.Outlook.OutlookAutoDiscoverProvider.GetADRecipientForRequestedUser(ADRecipientSession adRecipientSession, ADRecipient callerRecipient)

Did some more digging and found lots of references to the legacyExchangeDN being set to ADCDisabledMail (from legacy Exchange 5.5 ADC), but that wasn't my issue.  Tried searching for other AD objects with the same legacyExchangeDN, but nothing else popped up.  Finally found another mailbox with the same X500 email address in its ProxyAddresses.  I changed the X500 address of the other mailbox and the troubled mailbox could be opened without any further issue!
 
Why this didn't pop up in Exchange 2007?  Who knows.  But its something to look out for.

UPDATE (11-Oct-2011):  A Technet forum user called "Hotfix" posted a Powershell command that can be used to find users with an X500 address that points to an existing mailbox.  Hotfix wanted to post it here as a comment, but couldn't for some reason.  Here it is below:

# Gather all mailboxes.
$AllMailboxes = Get-Mailbox -ResultSize:Unlimited
# Check the LegacyExchangeDN of each mailbox.
$AllMailboxes | Foreach {
# Build the X500 address pattern match by pre-pending "X500:" in front of the mailbox LegacyExchangeDN.
$X500Address = "X500:" + $_.LegacyExchangeDN
# Perform a search for any recipient object with that X500 address. NOTE: This is not Exchange 2010 PowerShell remoting friendly.
$X500Check = Get-Recipient -Filter {EmailAddresses -eq $X500Address}
# If there was a match found, write it to the screen. This can be modified to be any type of desired output.
If ($X500Check) {
Write-Host $X500Check.PrimarySmtpAddress " - " $X500Address
}
}

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

CS "14" Beta Refresh Topology Publish Error

So, after returning from CS "14" Ignite training in shady, cool effin' hot Scottsdale, AZ, I was excited to install the beta refresh in my "lab" (which just so happens to be in our production environment....*cough cough*).  I uninstalled the beta before installing the refresh, as recommended by MS.  Everything seemed to go relatively well, with a few minor hiccups here and there, until it came to the point where I had to publish the topology.  I got this unhelpful error:

The existing topology identifies server mycs14serverFQDN\rtclocal as the CMS but the topology that you are trying to publish identifies server mycs14serverFQDN\rtlcocal as the CMS. The CMS must match before the topology can be published.

At first glance, it appears to be a rather odd message, since the server name is identical in both spots in the error message.  Since I hadn't changed the server name, I reasoned that Active Directory still had references to the old CMS database I removed from the beta.  CS "14" stores most of its data within the CMS database, instead of Active Directory.  The reason behind this is that its much easier to add functionality to a database than to have to extend the AD schema, and all the crap that goes along with it (approvals, hand-wringing, etc).  However, AD still has a few references to CS "14", like where to find the CMS database on the network.

Originally, I used ADSIEdit to remove the configuration store information from Active Directory.  THis caused some other issues with OCS R2, which were solved by further ADSIEdits to remove some other dead references to the failed CS "14" removal.  Recently, I found a better way to remove the configuration settings from Active Directory: Remove-CsConfigurationStoreLocation.  I saw this mentioned in one of the forums.  I haven't tried it yet, but I'm guessing this is a much better way to clean things up than my ADSIEdit method. 

Late to the party

Greetings all ("all" meaning 0 people at this point since this is my first posting).  I figured it was time for me to join the party and get myself a blog.  This blog will be used primarily to talk about Microsoft's UC offerings (OCS, Exchange and CS "14"). 

A bit about myself:  I'm a consultant with a company called Buchanan Technologies in Mississauga, Ontario (just outside of Toronto).  I'm also a virtual Technology Specialist (vTS) for Microsoft for OCS 2007 R2.  I've been a consultant with Buchanan for 10 years now (yikes!) and have really gotten on board the whole unified communications bit, especially Microsoft's offerings.  I worked at Microsoft a long, long LONG time ago as a support tech, and am pretty sure they installed a chip in my skull during one of the awesome parties they had back then.  To give you an idea on how long ago I worked at MS, the first product I supported was MS-DOS 6.2!  I moved on to greener pastures shortly after Windows 95 hit the scene, but still look back with fondness at those carefree days.

Thankfully, I've progressed since then (at least I hope so!) and this blog will prove useful to you!

Cheers!
Ken