Say Bye-Bye to Exchange Unified Messaging in Exchange Server 2019

Exchange Unified Messaging was first introduced in Exchange Server 2007 and has been in every version of Exchange server since - until now. In the Exchange Server 2019 Public Preview announcement it was revealed that UM is being dropped in Exchange Server 2019.

Exchange UM provides the following features and functionality:

• Access a full set of voicemail features from Internet-capable mobile phones, Microsoft Office Outlook (2007 and later), and Outlook on the web (OWA).
• Auto Attendants allow you to create sophisticated calling trees using both speech and keypad controls.
• Play on Phone lets you play voice messages on a telephone.
• The Outlook and OWA voicemail form includes the controls for actions such as playing, stopping, or pausing voice messages, playing voice messages on a telephone, and adding and editing notes.
• Call Answering Rules allow users to decide how incoming calls are answered.
• Voice Mail Preview provides (sometimes humorous) email transcriptions of voicemails which allow users to get a sense of the urgency of a recorded voicemail.
• Outlook Voice Access (OVA) allows users to access and manage their voicemails using voice or keypad controls.
• Protected Voice Mail enables users to send private voicemails protected by Active Directory Rights Management Services (AD RMS).
• For a full set of Exchange UM features see the article, Introduction to Microsoft Exchange Unified Messaging.

Exchange Server 2019 no longer includes Exchange Unified messaging. If your organization wants to migrate to Exchange 2019 and uses Exchange UM for company voicemail, you'll need to implement a new voicemail solution. Read on for some options.

The simplest option, of course, is to migrate everyone from on-premises to Office 365. Not only will you get Cloud Voicemail (aka Azure Voicemail), but you'll get all the hotness that only comes from the Office 365 -- Exchange Online, Teams, SharePoint Online, etc.

Organizations with no intention of using Office 365 will either need to implement a new voicemail system, or upgrade to or remain on Exchange 2016, the last Exchange Server version to support UM. In case it isn't obvious, this is because Cloud Voicemail runs in Office 365. Of course, upgrading to or staying on Exchange 2016 only buys you time. Mainstream support for Exchange 2016 is expected to end on October 13, 2020.

As announced on the EHLO Blog last year, Microsoft is discontinuing support for Session Border Controllers in Exchange Online in July 2018. Recently, they extended this deadline to April 30, 2019 due to customer feedback. This decision was surely a precursor of things to come (or not come, as it turns out) to Exchange Server 2019. Without SBC support, Cloud Voicemail will require Skype for Business Server as your on-prem PBX. You will not to be able to connect any other on-prem PBX, such as Cisco Call Manager or Avaya, to Cloud Voicemail.

Microsoft has received a lot of feedback from enterprise organizations about the removal of UM from Exchange and Exchange Online, as seen in the forum feedback above. It appears they may have misjudged how much this change will cost organizations and its impact to their customers. In an effort to reduce some of the cost, they have created a path to use Cloud Voicemail almost for free.

Customers running Exchange 2019 with Skype for Business Server 2019 with Enterprise Voice will be able to use Cloud Voicemail natively, as long as they have a tenant with at least one license that includes Skype for Business Online. No other licensing, gateways, or SBCs are required, but it will require implementing Azure AD Connect to sync your AD to your Azure AD for your tenant.

Customers running Exchange 2019 with Skype for Business Server 2015 with Enterprise Voice, or customers who cannot/will not have an Office 365 tenant, will have no other option than to use a third-party voicemail system. All voicemail support must come from the third-party provider.

I put together the following table that shows the different voicemail scenarios for Skype for Business and Exchange, both on-prem and in Office 365.

Enterprise Voice	Mailbox	Exchange UM	EXO UM	Cloud Voicemail
Skype for Business 2015	Exchange 2016	Yes	No	No
Skype for Business 2015	Exchange 2019	No	No	No
Skype for Business 2015	Exchange Online	No	Yes	No
Skype for Business 2019	Exchange 2016	Yes	No	No
Skype for Business 2019	Exchange 2019	No	No	Yes
Skype for Business 2019	Exchange Online	No	No	Yes
Skype for Business Online	Exchange 2016	No	No	Yes
Skype for Business Online	Exchange 2019	No	No	Yes
Skype for Business Online	Exchange Online	No	No	Yes
Skype for Business Online (No EV)	Exchange 2016	No	No	No
Skype for Business Online (No EV)	Exchange 2019	No	No	No
Skype for Business Online (No EV)	Exchange Online	No	No	No

Cloud Voicemail requires that the tenant has at least one license that includes Skype for Business Online to provide Cloud Voicemail capabilities for everyone in the tenant. It should be noted that in the preview Cloud Voicemail won't work if the organization is configured with Exchange hybrid, but this is expected to be fixed before General Availability. As a reminder, this is a preview, folks. Only try this stuff out in a lab.

An important feature for most companies is Auto Attendants. Currently, Auto Attendants in Phone System are rudimentary, but investments are being made to bring them up to feature parity previously available in Exchange UM. The biggest missing feature is the inability to invoke outbound calls from an Auto Attendant.

Cloud Voicemail features include simple voicemail, voicemail transcription with an MP3 attachment sent to the user's Inbox, ability to record personal greetings, message waiting indicator (MWI), and reply with call. It does not include Outlook integration like visual voicemail, Play on Phone, call answering rules, text notifications, or any Outlook Voice Access features. For further information on how to access Cloud Voicemail features, read Check Skype for Business voicemail and options.

So what do you think? Is this a big deal for your organization? Comments or questions? Leave a comment below.

Special thanks to fellow Office Servers & Apps MVP Adam Ball for help with the licensing aspects of this article.

EXPTA Consulting helps small, medium, and enterprise customers with their Exchange on-prem and Office 365 needs. We offer design, planning and migration services, identity and security solutions, and other IT services. Past customers include higher education, SAS providers, ITAR organizations, and insurance brokers. Contact us today to see how we can help you!

Read more ...

Announcing Exchange Server 2019 Public Preview

Today Microsoft announced the public preview for Exchange Server 2019. It is likely to reach general availability later this year.

Exchange 2019 continues to deliver the security, performance, and improved administration and management capabilities that customers expect, along with additional enhancements. Exchange Server 2019 can now be installed on Windows Server 2019 Core. This greatly reduces the attack surface of Exchange Server.

Search has been completely rewritten (again) to provide better and faster results. A side effect of this change is that it provides faster DAG failovers.

Performance improvements include reengineering to support bigger and better hardware. Exchange 2019 can now run on servers with up to 48 cores and 256GB RAM. Exchange 2019 will support the use of SSDs for tiered storage when it is released (it currently is not enabled in the preview build). More details on this will be released in September at Microsoft Ignite in Orlando.

A very important thing to know is that Exchange Server 2019 no longer supports Unified Messaging. Customers who currently use UM will need to move to another voicemail solution before they move to Exchange 2019.

Talk with EXPTA Consulting to understand your upgrade options.

Download the public preview here.

Read more ...

Discontinuation of Session Border Controllers in O365 and Why You Should Care

Microsoft announced today the Discontinuation of support for Session Border Controllers in Exchange Online Unified Messaging. This article is meant to explain what this means and why it's such a big deal.

UPDATES:

• Option 3, using TE-SYSTEMS anynode, is no longer a Microsoft recommended option.

• On April 24th Microsoft extended the date to remove SBCs from Office 365 to April 30, 2019, based on user feedback. This is only an extension. They have no intention of supporting SBCs after that date.

Session Border Controllers (SBCs) are used to route SIP-SIP traffic. They act as two-legged single-purpose firewalls, used only for SIP traffic. SBCs are usually deployed in the DMZ, where one interface faces the internal network (gateway/PBX) and the other faces the Internet (Office 365). They are required for all PBXs except Lync Server and Skype for Business to connect to Office 365 for voicemail or cloud PBX. Two SBCs are required for this communication, one on-prem and another Microsoft-owned SBC in Office 365. ß This is what is being retired.

VOIP gateways are needed when a legacy TDM-based PBX does not speak SIP. They translate TDM (PRI) to SIP. A SIP trunk connects the VOIP gateway to the SBC in DMZ.

Customers have one or more of the following types of telephone systems that link to Office 365 for voicemail:

3rd party TDM-based PBX (analog)
Examples include Avaya, AT&T Merlin, Nortel. Requires a voice gateway and SBS to connect to either Exchange UM or EXO UM.

3rd party IP-based PBX (digital)
Examples include Cisco CallManager. Requires an SBS to connect to either Exchange UM or EXO UM.

Lync Server/Skype for Business
Makes an authenticated federated call to the Lync Online service.

An Office 365 customer must create an IP Gateway in the tenant for SBC connectivity to Office 365. This creates a public DNS entry that looks like [GUID].um.outlook.com that maps to the SBC in Office 365. There will be one for each customer, but all on-prem SBCs connect to the same IP Gateway address, so the actual number of SBCs is really unknown.

UM Gateway in Exchange Server

The number of customers utilizing SBCs to connect to Office 365 may be small according to Microsoft, but these are usually very large customers with many SBCs. Once customers settle on a connectivity solution they continue to invest and expand on it. That's why it's such a big deal, especially for these customers.

According to today's announcement, the Office 365 SBCs are scheduled to be decommissioned in July 2018. If you're one of the customers who rely on SBCs to connect your on-premises PBX to Office 365 for Exchange UM or Azure voicemail, you have till then to make a change. As the article states, you have four options:

• Option 1: Complete migration from 3rd party on-premises PBX to Office 365 Cloud PBX.
• Option 2: Complete migration from 3rd party on-premises PBX to Skype for Business Server Enterprise Voice on-premises.
• Option 3: For customers with a mixed deployment of 3rd party PBX and Skype for Business, connect the PBX to Skype for Business Server using a connector from a Microsoft partner, and continue using Exchange Online UM through that connector. For example, TE-SYSTEMS’ anynode UM connector can be used for that purpose.
• Option 4: For customers with no Skype for Business Server deployment or for whom the solutions above are not appropriate, implement a 3rd party voicemail system.

Options 1, 2, and 4 are pretty well understood, but not trivial. Option 3, the anynode UM connector, requires a bit more explaining.

The anynode Skype for Business Voicemail Connector is a software SIP-to-SIP SBC solution that uses the Microsoft Unified Communications Managed API (UCMA) to communicate directly with Skype for Business Enterprise Voice. It's available from a German software company called TE-SYSTEMS (kind of reminds me of Geomant MWI for Exchange 2007 - anyone remember that?) This is great if your PBX already does SIP, but a number of large customers have analog PBXs in one or more locations. Traditional SBCs can convert analog PSTN calls to SIP using a Voice Gateway feature, and then trunk it over to Skype for Business or Skype for Business Online.

I can understand why Microsoft is discontinuing their SBCs in Office 365. It makes them rely on a third-party system that's sometimes difficult to manage. And after all, Microsoft is in business to sell services like Skype for Business and cloud PBX. But forcing customers to plan for and deploy all-new phone systems, SBC solutions, or voicemail systems in one year is asking a lot. Especially for the size of the customers they're affecting.

So what do you think? Will this tactic make you go "all in" for cloud PBX, as Microsoft hopes, or will it drive you toward one of the other solutions? Either way, you better get started now.

Read more ...

Fix for MSExchange Unified Messaging Event ID 1423 "A TLS API failure occurred. Error = 0x80090331"

I was working with a customer who is implementing Unified Messaging in an Exchange 2013 CU7 environment with Lync 2013. All Exchange servers are running on Windows Server 2012 R2. Exchange UM was configured properly, including setting the Unified Messaging Call Router and Unified Messaging services to "Dual" and configuring valid SSL certs for both UM services. The dial plans and Auto Attendants were created and they started to test.

Calls made to the UM enabled user would go to voicemail, the greeting would play, and the caller could record a voicemail, but the voicemail would not be delivered to the UM user's mailbox. We turned up UM logging using the following cmdlet:

Get-EventLogLevel "msexchange unified*" | Set-EventLogLevel -Level Expert

Another voicemail test showed the following MSExchange Unified Messaging event ID 1423 - A TLS API failure occurred. Error = 0x80090331.



A quick look in the %ExchangeInstallPath%\UnifiedMessaging\voicemail folder on the mailbox server hosting the UM user's mailbox showed all the voicemail WAV files queued for delivery.

I'm familiar with error code 0x80090301 on this event ID, which is caused by too many root certificates in the Trusted Root Certification Authorities store, but this code and error sting is different. 0x8009331 means, "SEC_E_ALGORITHM_MISMATCH - The client and server cannot communicate, because they do not possess a common algorithm." Definitely sounds like a TLS negotiation problem.

After double-checking the UM configuration and the SSL certificate configuration used by the UM services it was found that TLS 1.0 was disabled for clients on the Exchange 2013 servers. The registry key HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client\DisabledByDefault was set to 1. This key doesn't exist by default and was not being configured via GPO, so it must have been configured in their server build. Setting the value to 0 (or deleting the DisabledByDefault key) fixed the problem.

The problem occurred because the UM server acts as both a client and a server to itself. The UM service acts as a client when it reads the voicemail WAV files from the voicemail folder and uses TLS to do so.

Note that there were several improvements to TLS and SSL in Exchange 2013 CU8 and Exchange 2010 SP3 RU9. These versions support TLS 1.1 and 1.2, which should also work. Please read Scott Landry's excellent article, Exchange TLS & SSL Best Practices, for more information.

Read more ...

Inbox Rules Do Not Work on Unity Connections 8.5.1 Messages

I ran into this with a customer recently and wanted to document what I found.  The customer is using Cisco Unity Connections 9.1 for voicemail with Single Inbox and Exchange 2010 SP3.

Cisco's Single Inbox provides a UM experience similar to Exchange Unified Messaging, where voicemails are delivered to the user's Inbox as emails with attached WAV files.  The voicemail messages are linked by Unity Connections so that if a user deletes a voicemail in Unity, the email message is also deleted.  Likewise, if the user deletes the voicemail email message in Exchange the voicemail is deleted in Unity.

Unity Connections 8.5.x and later uses Exchange Web Services (EWS) for connectivity to Exchange 2007 and Exchange 2010 mailboxes using a service account.  How Unity programmatically does this is a mystery since it is not documented anywhere in Cisco's documentation.

The issue here is that the way Unity Connections Single Inbox creates the message in the recipient's mailbox bypasses the rules table associated with the mailbox.  The result is that rules don't fire for these messages.  For example, it's common for users to create an Inbox rule that moves messages from Unity Connections to a custom folder like "Voicemails".  If you manually run the rule it works as expected.

This issue is documented somewhat in the Cisco Community Forums here: https://supportforums.cisco.com/docs/DOC-17854.  A comment in this forum post implies this is an Exchange bug, but I've confirmed that Inbox rules fire correctly when messages are sent via EWS in a normal manner.  Fellow Exchange MCM, Mike Pfeiffer, has a great post on Sending Email with PowerShell and the EWS Managed API.  I used this PowerShell function to send emails using EWS and test Inbox rules, which worked perfectly.

I've tried every creative trick I know to work around this issue, to no avail.  In the end, there's really nothing that can be done to fix this until Cisco changes to the way it sends Single Inbox messages using EWS.

Read more ...

How to Configure a Disaster Information Message in Exchange 2010 UM

Exchange 2010 Unified Messaging can be used to create a disaster information message for employees.  Typically you will have a dedicated phone number for this purpose and will advertise this number to employees on a regular basis.  When a disaster occurs a DR coordinator calls into Exchange UM and records a message for employees, giving them information and instructions.  You may want to visit Talking About Disaster for information and ideas about what to include in your disaster information message.

This article explains how to create an auto attendant for this purpose and how to configure Exchange to allow greetings to be recorded using the telephone user interface (TUI).  I assume that you already are using Exchange Unified Messaging and that it's configured properly. 

Let's get started.

• Create a new enabled* Auto Attendant called “Disaster Announcement” with a Pilot Identifier for the disaster information extension.

• Open the properties of the new auto attendant.  On the General tab, disable speech-enabled and directory enabled. 


• Set the Business Hours Greeting and Business Hours Main Menu Prompt to use the C:\Program Files\Microsoft\Exchange Server\V14\UnifiedMessaging\prompts\en\Silence-250ms.wav file. This will set the prompts to silence.   Alternatively, you may want to use a WAV file saying, “There are no disasters right now. Call back later” for the Main Menu prompt. 


• Set the Times tab to Always Run. 


• Clear all the options in the Features tab. 


• Configure a new Key Mapping called “Announcement” that runs the “Disaster Announcement” auto attendant (itself) when the user presses no key (time-out). This will cause the auto attendant to loop.  Alternatively, you can configure it to play the Silence-250ms.wav file, which will loop indefinitely until the caller gets bored of hearing nothing and hangs up. 

• Clear all the options on the Dialing Restrictions tab and click OK to save the changes.

Then use the TUI to configure the auto attendant greeting when a disaster occurs.   Read Enable Custom Prompt Recording Using the Telephone User Interface for instructions on how to do this.

* If you create the auto attendant as disabled you will run into an interesting problem where you cannot save the AA configuration changes because the AA references a disabled AA (itself).

Read more ...

How to Reset Exchange 2010 MWI

Exchange 2010 has native message waiting indicator (MWI) support.  This feature enables the MWI light on your business phone when you receive a new voicemail in Exchange 2010 Unified Messaging (UM).  When a voicemail is received by the UM server it sends a SIP command to the PBX to tell it to turn the MWI on.  MSExchange Unified Messaging event 1343 is logged if diagnostic logging is turned up on the Exchange 2010 UM server:

(BTW, have I ever mentioned how much I hate typos in event logs?  Succesfully?  Really?)

Exchange 2010 reads the Voice Mail search folder to know if there are any unread voicemail messages.  If there are, it sends the SIP message above.  Simply marking a voicemail as unread should enable the MWI and cause the event to be logged.

The Voice Mail search folder is created when you UM enable a mailbox.  Exchange Web Services (EWS) is responsible for creating this search folder.

Sometimes Exchange 2010 is unable to read the Voice Mail search folder due to corruption.  I've seen this happen when mailboxes are migrated from Exchange 2007, which has no native MWI support, and third-party MWI software is used, such as Geomant MWI for Microsoft Unified Messaging.  In this case you need to delete and recreate the Voice Mail search folder from Outlook.

Note: You cannot delete the Voice Mail search folder using OWA since it treats it as a protected folder.  You must delete it using Outlook 2007 or 2010.

But what happens if you delete the Voice Mail search folder?  Well, bad things happen in MWI land.  You'll notice that there are no 1343 events logged for that user anymore and the MWI light will not change.  If it was on, it stays on.  If it was off, it stays off.  The fix is to have EWS recreate the folder.  You cannot create this special search folder manually, you need EWS to do it.

David Sterling, a Senior Software Development Engineer on the Microsoft Exchange Web Services Team, wrote an excellent post about the Voice Mail search folder and how to recreate it.  Fellow MCM Keif Machado and I spent quite a while trying to get it to work at a customer before we discovered that it only works in Exchange online mode.

Here are the steps to delete and recreate the Voice Mail search folder to fix MWI:

1. Make sure that Outlook is running in online mode (Not Cached Exchange Mode).  In online mode Outlook will say "Online with Microsoft Exchange" in the status bar, not "Connected with Microsoft Exchange".
2. Delete the Voice Mail search folder in Outlook.  This only deletes the search folder, not the messages.
3. Dial into Outlook Voice Access to access your old voicemails.  You need to enter the "voice mail" command, even if OVA says you have no new voicemails.  When you do this, EWS will recreate the Voice Mail search folder in Outlook.  Hang up.
4. Reconfigure Outlook to use Cached Exchange Mode again and restart Outlook.  Since the OST header still matches the mailbox database header, Outlook will use the same OST and will resync your emails quickly and easily.

Now test MWI functionality by marking voicemails as unread in the Voice Mail search folder and by leaving a new voicemail.

Read more ...

Introducing LyncAddContacts!

The Office Communications Server 2007 Resource Kit Tools featured a nifty tool called LCSAddContacts.  This WSF script allows you to add contacts to LCS or OCS (but not Lync Server) using WMI.  I was hoping to see a version of this tool for Lync Server, but no such luck -- So I wrote one myself.

I'm surprised to find that there is no PowerShell cmdlet that allows you to add contact groups or contacts, and since there are no WMI classes for Lync Server anymore, I needed a way to do this -- so I wrote a tool myself.  I leverage the DBIMPEXP utility from the Lync Server DVD to import and export contacts. 

The purpose of LyncAddContacts is to add the same contact groups and contacts to multiple users programmatically.  For example, you may want to import a contact group called "Company Contacts"  that contains contacts for everyone in the company.  Here's how it works:

1. Create a template (source) user in Lync with the contact groups and contacts that you want to export.
2. Run the LyncAddContacts tool to export the source user's contacts
3. Run the LyncAddContacts tool again in import mode and target the user or OU that you want to import the contacts to.

Prerequisites:

• The tool must be run on the Lync server from which you will export/import the data.
• You must be a member of the CSAdministrator security group to run this tool.  This group has rights to export and import contact groups and contacts to all users.
• You must copy the DBIMPEXP.EXE tool from the \Support folder on the Lync Server 2010 installation media to the same folder where the LyncAddContacts tool will be run.
• You must have read, write and execute rights to the folder where the LyncAddContacts tool will be run.

Note: This tool must be run under the CScript host due to the amount of output generated.  You will see a syntax pop-up window if the tool runs under WScript.

Usage:

LyncAddContacts uses the following syntax:

CScript LyncAddContacts.vbs /backup filename.xml [FE SQL server host name[\Instance]]
CScript LyncAddContacts.vbs SIPAddress [FE SQL server host name[\Instance]]
CScript LyncAddContacts.vbs /import SIPAddress | distinguished name of OU [FE SQL server host name[\Instance]]

The following examples demonstrate how to use the tool.

---

Use the /backup switch to backup all user data to the specified filename.  The following example backs up user data on a Lync Standard Edition server:

CScript LyncAddContacts.vbs /backup backup.xml

where backup.xml is the backup filename.

The following example performs the same backup on a Lync Enterprise Edition server:

CScript LyncAddContacts.vbs /backup backup.xml sql.domain.com

where backup.xml is the backup filename and sql.domain.com is the SQL server used by the front-end pool.

Once the backup has been performed, you can begin the export/import process.

---

First, you must export the source user's contact groups and contacts.  The following example exports this information from a user named "Source" on a Lync Standard Edition server:

CScript LyncAddContacts.vbs source@domain.com

where source@domain.com is the SIP address of the user you want to export.

The following example performs the same export on a Lync Enterprise Edition server:

CScript LyncAddContacts.vbs source@domain.com sql.domain.com

where source@domain.com is the SIP address of the user you want to export and sql.domain.com is the SQL server used by the front-end pool.

---

Second, you import the contact groups and contacts to either a single target user or a target Organizational Unit in your domain.  The following example imports the data to a user named "Target" on a Lync Standard Edition server:

CScript LyncAddContacts.vbs /import target@domain.com

where target@domain.com is the SIP address of the user you want to import the contact info to.  For Lync Server Enterprise Edition you must add the SQL server used by the front-end pool, as shown above.

The following example imports the same contact groups and contacts to all the SIP enabled users in the Users container in Active Directory:

CScript LyncAddContacts.vbs /import CN=Users,DC=domain,DC=com

Again, for Lync Server Enterprise Edition you must add the SQL server used by the front-end pool. 
In this example, were also specifying the SQL instance LyncServer:

CScript LyncAddContacts.vbs /import "OU=Lync Users,DC=domain,DC=com" sql.domain.com\LyncServer

A nice benefit of this tool is that contacts will not get a notification that so-and-so has added them to their contact list.  This is really useful in preventing unnecessary pop-ups from the Lync client.

---

Download LyncAddContacts.  View the source code here.

---

Disclaimer: I hope that the information in this blog is valuable to you. Your use of the information contained in these pages, however, is at your sole risk. All information on these pages is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by The EXPTA {blog}. Further, EXPTA shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.

Read more ...

Testing Speech Grammars

In an earlier post I wrote about speech grammars in Lync Server and Exchange Unified Messaging.

Here's a simple VBScript that uses the same speech method to hear how speech-enabled programs pronounce words.  This is useful to determine how these programs will pronounce proper names.

sText = InputBox("Enter the text you want the computer to say.", "Text to Speech")
sText = Trim(sText)
If sText <> "" Then
     set sapi = CreateObject("sapi.spvoice")
     sapi.Speak sText
End If

To accomplish the same thing in PowerShell, use the following:

$Voice = New-Object -com SAPI.SpVoice
$Voice.Speak( "Keith Johnson" )

For example, if you enter my name as it's spelled (Jeff Guillet) you will hear how speech enabled applications mispronounce my name.  In the case of Exchange UM directory lookups, this is also how Exchange expects callers to pronounce my name to find a match.  If you enter the phonetic spelling of my name (Jeff GheeA) you will hear it pronounced correctly. 

By testing different phonetic spellings using these scripts, you can determine what to use for the msDS-PhoneticDisplayName attribute in Active Directory.

Read more ...

Changing Name Pronunciation in Lync Server 2010

Lync Server 2010 uses speech grammars to make meeting entry and exit announcements.  For example, "Jeff Guillet is now joining" is played to all meeting participants when I join a Lync meeting if the meeting is configured to play announcements.

Lync mispronounces my last name as "Ghill-ett" instead of "Ghee-AY", so I have a vested interest in finding out how to correct this.  :)

Unfortunately, it's not doable in Lync 2010 RTM since Lync reads the user's displayName attribute in Active Directory for announcements.  If I change the displayName attribute to a phonetic spelling of my name, "Jeff GheeA", it affects how my name is displayed to other users in Exchange 2010 and the Global Address List (GAL).  Bummer.  :(

Exchange 2010 Unified Messaging has a more mature way of handling speech grammars.  It uses the msDS-PhoneticDisplayName attribute, if it is set, to pronounce a name.  If msDS-PhoneticDisplayName is not set (it's not by default), Exchange uses the displayName attribute.  You can use ADSIEdit to set the msDS-PhoneticDisplayName value.

This not only affects how Exchange UM pronounces a name, it also affects voice-enabled directory lookups.  For example, if someone using a Outlook Voice Access auto attendant tries to look up my name using the correct pronunciation, "Ghee-ay", Exchange will find a match.  Without setting the msDS-PhoneticDisplayName attribute, users may need to mispronounce my name to find a match.

For a more detailed explanation of Exchange speech grammars, see Speech Recognition of Names by Exchange 2007 Unified Messaging on the Exchange Team blog.

I'm hopeful that Lync will be updated to use the msDS-PhoneticDisplayName attribute in a future release.

Read more ...