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"

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 make obtaining the raw data relatively easy, but manually working that data into something manageable is extremely difficult.

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 29884 typ host
a=candidate:1 2 TCP-PASS 2120613374 29884 typ host
a=candidate:2 1 TCP-ACT 2121006591 19511 typ host
a=candidate:2 2 TCP-ACT 2121006078 19511 typ host
a=candidate:3 1 TCP-PASS 6556159 57733 typ relay raddr rport 22533
a=candidate:3 2 TCP-PASS 6556158 57733 typ relay raddr rport 22533
a=candidate:4 1 TCP-ACT 7076607 57733 typ relay raddr rport 22533
a=candidate:4 2 TCP-ACT 7076094 57733 typ relay raddr 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 address is the internal address of the other user, while the 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...

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  :)


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 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, the Exchange 2010 CAS will redirect the user to an externally accessible Exchange 2007 CAS using a different URL (like  The redirection is silent, but the user may notice their browser changed to

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, 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, 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=">
Replace 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 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:

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:
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,

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.

Friday, September 3, 2010

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:;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.

Tuesday, August 31, 2010

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.

Monday, August 30, 2010

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.

Tuesday, August 24, 2010

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

Monday, August 23, 2010

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!

Tuesday, August 17, 2010

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!

Monday, August 16, 2010

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!